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.

You basically want to compare the "Legacy code name and value" values at https://heycam.github.io/webidl/#dfn-error-names-table with the constants listed in https://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, https://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.

OK, cool. Combined with things like https://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 :(.)

Oops, I meant https://www.w3.org/Bugs/Public/show_bug.cgi?id=27284

> 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 https://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.

In the "entries API" (i.e. Chrome's directory upload, now being shipped by FF and Edge) - https://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 https://wicg.github.io/entries-api/#issue-bfc3b40a

Fixed in https://github.com/heycam/webidl/commit/c50ffc4.