27732 2015-01-03 10:30:15 +0000 DOMException lost some constants. 2016-12-09 12:59:48 +0000 1 1 1 Unclassified WebAppsWG WebIDL unspecified All All RESOLVED FIXED P2 normal --- 1 Ms2ger cam bzbarsky d jsbell mike Ms2ger public-script-coord tobie.langel public-webapps-bugzilla oldest_to_newest 116738 0 Ms2ger 2015-01-03 10:30:15 +0000 There's no reason to drop DOMException.DOMSTRING_SIZE_ERR and friends. 127929 1 d 2016-10-22 16:28:50 +0000 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. 127936 2 bzbarsky 2016-10-23 01:16:58 +0000 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. 127937 3 d 2016-10-23 01:48:17 +0000 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 :(.) 127938 4 d 2016-10-23 01:48:56 +0000 Oops, I meant https://www.w3.org/Bugs/Public/show_bug.cgi?id=27284 127940 5 bzbarsky 2016-10-23 21:15:10 +0000 > 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. 128016 6 jsbell 2016-11-01 18:39:58 +0000 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 128307 7 tobie.langel 2016-12-09 12:59:48 +0000 Fixed in https://github.com/heycam/webidl/commit/c50ffc4.