Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Error conventions for extensions #701

@kainino0x

Description

@kainino0x

Moved from #696 (comment)

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.

Metadata

Metadata

Assignees

Labels

copyeditingPure editorial stuff (copyediting, *.bs file syntax, etc.)

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions