This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27732 - DOMException lost some constants.
Summary: DOMException lost some constants.
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
Depends on:
Reported: 2015-01-03 10:30 UTC by Ms2ger
Modified: 2016-12-09 12:59 UTC (History)
7 users (show)

See Also:


Description Ms2ger 2015-01-03 10:30:15 UTC
There's no reason to drop DOMException.DOMSTRING_SIZE_ERR and friends.
Comment 1 Domenic Denicola 2016-10-22 16:28:50 UTC
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.
Comment 2 Boris Zbarsky 2016-10-23 01:16:58 UTC
You basically want to compare the "Legacy code name and value" values at with the constants listed in and see which ones are missing.  But really, they're the ones that correspond to numeric gaps in the webidl table.


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, 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.
Comment 3 Domenic Denicola 2016-10-23 01:48:17 UTC
OK, cool. Combined with things like, 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 :(.)
Comment 4 Domenic Denicola 2016-10-23 01:48:56 UTC
Oops, I meant
Comment 5 Boris Zbarsky 2016-10-23 21:15:10 UTC
> 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
   implementation, but I don't know whether that error ever propagates out to
   content script.

so it might just be getRandomValues in practice.
Comment 6 Joshua Bell 2016-11-01 18:39:58 UTC
In the "entries API" (i.e. Chrome's directory upload, now being shipped by FF and Edge) - - 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
Comment 7 Tobie Langel 2016-12-09 12:59:48 UTC
Fixed in