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. > > 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/CAM0wra8Z-v2LesvcL3QdCtSVzsAV3qi4AZXjmyT1zzbScEcY4Q%40mail.gmail.com.
