Sorry, I misunderstood which way this change was being proposed. LGTM1 On Tuesday, May 13, 2025 at 6:24:02 PM UTC-7 Domenic Denicola wrote:
> 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/9f6747c4-94d9-4063-9ea5-89bbab2eeb57n%40chromium.org.
