LGTM3 On Thu, May 15, 2025 at 8:07 AM Vladimir Levin <vmp...@chromium.org> wrote:
> > > On Wednesday, May 14, 2025 at 8:53:30 PM UTC-4 Domenic Denicola wrote: > > On Thu, May 15, 2025 at 12:26 AM Vladimir Levin <vmp...@chromium.org> > wrote: > > Hi, > > I'm looking at https://github.com/search?q=QuotaExceededError&type=code > it seems like there are already classes with that name, which I believe > shouldn't be a problem. > > > Notably the majority of cases I can find are in React Native and Node.js > code. > > > I do see some patterns that check explicitly for QuotaExceededError string > and some examples handle that as a "success" as in: the request succeeded > but some caching mechanism exceeded a quota, which is ok. The proposed > change here would break these cases, is that right? > > > I'm not sure which cases you're referring to. By "check explicitly for the > QuotaExceededError string", do you mean the pattern `ex.name === > "QuotaExceededError"`? If so, that is listed in the explainer as one of the > patterns that will not break. > > > Ah my bad, I didn't realize that the name would continue to be > QuotaExceededError. Sounds good, no concerns from me. (I believe Chris > plans to be the third approver here) > > Thanks, > Vlad > > > > > > Thanks, > Vlad > > On Wednesday, May 14, 2025 at 11:23:28 AM UTC-4 Daniel Bratell 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/6bf5d5be-b2ff-4270-b3b8-116b7e752bc5n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6bf5d5be-b2ff-4270-b3b8-116b7e752bc5n%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/CAOMQ%2Bw-X0ywVSZanuQWbyDz%2Bj9ScaTRLg3mmbdoefvMKqzRmFg%40mail.gmail.com.
