- From: <bugzilla@jessica.w3.org>
- Date: Sun, 23 Oct 2016 01:16:58 +0000
- To: public-script-coord@w3.org
https://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 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. -- You are receiving this mail because: You are on the CC list for the bug.
Received on Sunday, 23 October 2016 01:17:09 UTC