Intent to Ship: Update QuotaExceededError to a DOMException derived interface

[Ayu Ishii]

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

TAG review

Review request filed & closed

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?

To be added here

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.

[Dan Clark]

Can you please request the other review bits in ChromeStatus (privacy, security, etc)?

-- Dan

[Alex Russell]

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. Should we cite to that? And should the principles be updated to discuss not using subclasses with this sort of specific example?

Best,

Alex

[Domenic Denicola]

On Wed, May 14, 2025 at 3:21 AM Alex Russell <sligh...@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. 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, 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?

[Alex Russell]

Sorry, I misunderstood which way this change was being proposed. LGTM1

[Daniel Bratell]

LGTM2

/Daniel

--
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+...@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.

[Vladimir Levin]

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. 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?

Thanks,

Vlad

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Chris Harrelson]

Looks good to me, once the Testing dimension is filled out on chromestatus.com.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/afd9ed04-bcc0-4713-95c6-a7e1e90fa307%40gmail.com.

[Ayu Ishii]

Thank you for all the reviews! (And apologies for the delayed review bits!)

Best,
Ayu

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@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.

--
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+unsubscribe@chromium.org.

[Domenic Denicola]

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

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Vladimir Levin]

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

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Chris Harrelson]

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@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.