On Wed, May 14, 2025 at 3:21 AM Alex Russell <slightly...@chromium.org> wrote:
> Thanks for flipping the bits, Ayu. > > Domenic: it seems like this is part of a longer-running set of changes > we've had going in DOM-land regarding moving away from subclasses of Error > types, and IIRC this is a motivating factor in the TAG's Design > Principles guidance on error types > <https://www.w3.org/TR/design-principles/#error-types>. Should we cite to > that? And should the principles be updated to discuss not using subclasses > with this sort of specific example? > I'm not sure what longer-running set of changes you're referring to. Subclassing of Error is pretty common; the JavaScript spec itself does so; web developers commonly do so; and web specifications do a fair amount. (We added first-class support for doing so on the web platform in 2022 <https://github.com/whatwg/webidl/pull/1211>, paving the cowpath set by WebTransportError, RTCError, GPUPipelineError, and a few others.) This is just the latest in a long list of such additions. This change, as well as all those previous ones, seems fully aligned with the TAG Design Principles. They are all subclasses of Error. (Because DOMException is a subclass of Error.) I don't understand the suggestion to update the principles. Are you saying they should be changed to the opposite of what they are saying now, and to discuss *not* using subclasses? Why? > > Best, > > Alex > > On Tuesday, May 6, 2025 at 5:28:48 PM UTC-7 dan...@microsoft.com wrote: > >> Can you please request the other review bits in ChromeStatus (privacy, >> security, etc)? >> >> -- Dan >> >> On Tuesday, May 6, 2025 at 3:42:02 PM UTC-7 ay...@chromium.org wrote: >> >>> Contact emails >>> >>> ay...@chromium.org, dom...@chromium.org >>> >> >>> Explainer >>> >>> https://github.com/whatwg/webidl/pull/1465 >>> >>> Specification >>> >>> https://github.com/whatwg/webidl/pull/1465 >>> >>> Summary >>> >>> Currently, when the web platform wants to tell you when you've exceeded >>> quota, it will use `DOMException` with the specific `name` property set to >>> `QuotaExceededError`. However this does not allow carrying additional >>> information. >>> >>> This proposes removing "QuotaExceededError" from the list of built-in >>> `DOMException` names, and instead creates a class name `QuotaExceededError` >>> from the list of built-in `DOMException` and has the additional optional >>> properties `quota` and `requested`. We propose all instances of specs that >>> throw "QuotaExceededError" `DOMException`s get upgraded to instead throw >>> `QuotaExceededError`s. For now, such specs would leave the `quota` and >>> `requested` properties at their default value of `null`, but they could >>> eventually upgrade to include that data, if it's useful for their use case >>> (and isn't, e.g., a privacy leak). >>> >>> >>> Blink component >>> >>> Blink >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%22> >>> >>> TAG review >>> >>> Review request filed & closed >>> <https://github.com/w3ctag/design-reviews/issues/1065> >>> >>> TAG review status >>> >>> N/A >>> >>> Risks >>> >>> Interoperability and Compatibility >>> >>> This is technically backward-incompatible with some rare coding >>> patterns. The spec PR outlines those, and compares them with the more >>> common coding patterns which work the same even after this change. Given >>> that quota exceeded exceptions only occur in rare cases anyway, and the >>> most popular patterns will continue working with no problem, we think the >>> compat risk here is small. Nevertheless, we'll carefully monitor for >>> breakage, and use Finch to revert if any serious problems are found. >>> >>> We anticipate low interoperability risk, as we suspect that if Chromium >>> proves that this is web-compatible, other browsers will quickly follow. And >>> even during the transition period, the most common coding patterns will >>> work in all browsers. >>> >>> >>> >>> Gecko: Under consideration ( >>> https://github.com/mozilla/standards-positions/issues/1223) >>> >>> WebKit: Pending ( >>> https://github.com/WebKit/standards-positions/issues/468) >>> >>> Web developers: No signals >>> >>> Other signals: >>> >>> Ergonomics >>> >>> None >>> >>> >>> Activation >>> >>> N/A >>> >>> >>> Security >>> >>> None >>> >>> >>> WebView application risks >>> >>> Does this intent deprecate or change behavior of existing APIs, such >>> that it has potentially high risk for Android WebView-based applications? >>> >>> None >>> >>> >>> Debuggability >>> >>> None >>> >>> >>> Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, ChromeOS, Android, and Android WebView)? >>> >>> Yes >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ? >>> >>> To be added here >>> <https://crsrc.org/c/third_party/blink/web_tests/external/wpt/webidl/ecmascript-binding/es-exceptions/DOMException-constructor-behavior.any.js> >>> >>> Flag name on about://flags >>> >>> None >>> >>> Finch feature name >>> >>> QuotaExceededError >>> >>> Requires code in //chrome? >>> >>> False >>> >>> Measurement >>> >>> N/A >>> >>> Estimated milestones >>> >>> M138 >>> >>> >>> Anticipated spec changes >>> >>> Open questions about a feature may be a source of future web compat or >>> interop issues. Please list open issues (e.g. links to known github issues >>> in the project for the feature specification) whose resolution may >>> introduce web compat/interop risk (e.g., changing to naming or structure of >>> the API in a non-backward-compatible way). >>> >>> We haven't yet sent spec PRs to update all specifications to use this >>> new error type, but that process is pretty mechanical, and we will do so >>> once we're sure this sticks. We want to avoid badgering 9 separate spec >>> editors into merging our update PRs, if there's a possibility we'd then >>> have to badger them to accept 9 separate revert PRs a couple months later. >>> >>> >>> Link to entry on the Chrome Platform Status >>> >>> https://chromestatus.com/feature/6194847180128256?gate=5011647107956736 >>> >>> This intent message was generated by Chrome Platform Status >>> <https://chromestatus.com/>. >>> >>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-QxRC-THKg4KxQ0Q0Bh6BEzrjfNkO6meWHREw2RBd11A%40mail.gmail.com.
