[Bug 27732] DOMException lost some constants.

# bugzilla at jessica.w3.org (7 months ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=27732

Domenic Denicola d@domenic.me changed:

       What    |Removed                     |Added

          Flags|                            |needinfo?(Ms2ger@gmail.com)
             CC|                            |d@domenic.me,
               |                            |Ms2ger@gmail.com

--- Comment #1 from Domenic Denicola d@domenic.me ---

Ms2ger, what is the complete list of constants that were lost? We should test that all browsers have them, and if so reintroduce them, but without such a list there's not much to do.

Contact us to advertise here
# bugzilla at jessica.w3.org (7 months ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=27732

Boris Zbarsky bzbarsky@mit.edu changed:

       What    |Removed                     |Added

             CC|                            |bzbarsky@mit.edu

--- Comment #2 from Boris Zbarsky bzbarsky@mit.edu ---

You basically want to compare the "Legacy code name and value" values at heycam.github.io/webidl/#dfn-error-names-table with the constants listed in www.w3.org/TR/DOM-Level-3-Core/core.html#ID-17189187 and see which ones are missing. But really, they're the ones that correspond to numeric gaps in the webidl table.

At first glance: DOMSTRING_SIZE_ERR = 2, NO_DATA_ALLOWED_ERR = 6, VALIDATION_ERR = 16, TYPE_MISMATCH_ERR = 17.

Note that the web platform test at WebIDL/ecmascript-binding/es-exceptions/DOMException-constants.html does test for their existence, as far as I can see, and would fail in a browser that doesn't support them.

Apart from that and the actual occurrence in the WebIDL for DOMEXception, I don't see any uses of DOMSTRING_SIZE_ERR, NO_DATA_ALLOWED_ERR, or VALIDATION_ERR in Gecko, which makes sense because the situations they would arise in for the DOM3 Core spec never arise on the web in practice, I think.

TYPE_MISMATCH_ERR is totally used, in both code and specs. For example, w3c.github.io/webcrypto/Overview.html#Crypto-method-getRandomValues step 1 uses it (the "throw TypeMismatchError" bit). So its removal from DOMException breaks various stuff even if we ignore the "match UAs" aspect of things.

# bugzilla at jessica.w3.org (7 months ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=27732

Domenic Denicola d@domenic.me changed:

       What    |Removed                     |Added

          Flags|needinfo?(Ms2ger@gmail.com) |

--- Comment #3 from Domenic Denicola d@domenic.me ---

OK, cool. Combined with things like www.w3.org/Bugs/Public/show_bug.cgi?id=29372, it sounds like we should be sure when reintroducing to mark these as deprecated/do-not-use somehow. (I'm very sad people are using TypeMismatchError instead of TypeError :(.)

# bugzilla at jessica.w3.org (7 months ago)
# bugzilla at jessica.w3.org (7 months ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=27732

--- Comment #5 from Boris Zbarsky bzbarsky@mit.edu ---

I'm very sad people are using TypeMismatchError instead of TypeError

The uses I see in Gecko that are standards-related are:

1) The getRandomValues case I already mentioned. 2) Something in the dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html implementation, but I don't know whether that error ever propagates out to content script.

so it might just be getRandomValues in practice.

# bugzilla at jessica.w3.org (7 months ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=27732

Joshua Bell jsbell@google.com changed:

       What    |Removed                     |Added

             CC|                            |jsbell@google.com

--- Comment #6 from Joshua Bell jsbell@google.com ---

In the "entries API" (i.e. Chrome's directory upload, now being shipped by FF and Edge) - wicg.github.io/entries-api - calling dirEntry.getDirectory() with a path that resolves to a file, or dirEntry.getFile() with a path that resolves to a directory, results in a TypeMismatchError asynchronous result.

That's an odd one; it doesn't feel much like a TypeError to me, which is usually related to script types.

This is a legacy API we're trying to standardize so we have some wiggle room as implementations converge; we managed to switch Chrome from FileError to DOMException, for example, since the names matched and we'd deprecated code. Noting it here for completeness, tracked in the spec as wicg.github.io/entries-api/#issue-bfc3b40a

# bugzilla at jessica.w3.org (6 months ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=27732

Tobie Langel tobie.langel@gmail.com changed:

       What    |Removed                     |Added

     Resolution|---                         |FIXED
             CC|                            |tobie.langel@gmail.com
         Status|NEW                         |RESOLVED

--- Comment #7 from Tobie Langel tobie.langel@gmail.com ---

Fixed in heycam/webidl/commit/c50ffc4.

Want more features?

Request early access to our private beta of readable email premium.