Error conventions for extensions

Question

Moved from https://github.com/gpuweb/gpuweb/issues/696#issuecomment-612172179

Context:

Adding members to dictionaries in WebIDL is (technically) a breaking change. Members that were previously ignored are now typechecked, which introduces new exceptions in existing code.

Extensions make the story here more complicated, as our dictionaries are expected to grow over time (as extensions are added) some extensions may be unimplemented by some browsers.

Additionally, there's a principle to make the following cases behave the same way on the device: the browser doesn't implement the extension; the extension is not available due to the hardware; the extension is not enabled by the user on the device.

Option 0:

Note also that the error conventions, as currently stated, mean the API should reject any usage of an extension if it's not available.

If any object in A contains any key that is not core or part of an enabled extension: Error must be synchronous. This is explicitly made more strict than the usual WebIDL dictionary binding rules.

Unfortunately it is currently unimplemented in the spec and not implementable directly in WebIDL.

Option 1:

For portability (between browsers), it's necessary to have either this rule, or a replacement one that says:

All dictionary members from extensions must be optional and have type WebIDL type any. This makes using them valid, and behave the same, if either unsupported by the browser or not enabled on the device. Type checking rules must be defined in the specification such that they apply only when the extension is enabled on the device.

该提问来源于开源项目：gpuweb/gpuweb

Answer 1

Option 2:

We decided on the editors call that we should change the error conventions currently recorded in ErrorConventions.md:

1. probably just take the (fairly small) backward/cross-browser compatibility hit that the rest of the web platform is already subject to (which is that adding an optional field to a WebIDL dictionary is a breaking change because it adds type checking to a field that previously was ignored).
2. consider implementing warnings for any unrecognized dictionary members.