Looks good to me, once the Testing dimension is filled out on chromestatus.com.
On Wed, May 14, 2025 at 8:23 AM Daniel Bratell <bratel...@gmail.com> wrote: > LGTM2 > > /Daniel > On 2025-05-14 17:22, Alex Russell wrote: > > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9f6747c4-94d9-4063-9ea5-89bbab2eeb57n%40chromium.org?utm_medium=email&utm_source=footer> > . > > -- > 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/afd9ed04-bcc0-4713-95c6-a7e1e90fa307%40gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/afd9ed04-bcc0-4713-95c6-a7e1e90fa307%40gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAOMQ%2Bw_B1omT%2BkeToL1GNSaMKkevGneHkFVO-%2BZG3FD-f2GrMA%40mail.gmail.com.
