Updating QuotaExceededError to a DOMException derived interface

[ayuishii]

Specification title

QuotaExceededError

Specification or proposal URL (if available)

whatwg/webidl#1465

Explainer URL (if available)

No response

Proposal author(s)

@domenic

MDN URL

https://developer.mozilla.org/en-US/docs/Web/API/DOMException#quotaexceedederror

Caniuse.com URL

https://caniuse.com/mdn-api_domexception

Bugzilla URL

No response

Mozillians who can provide input

@smaug----

WebKit standards-position

WebKit/standards-positions#468

Other information

Description
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" DOMExceptions get upgraded to instead throw QuotaExceededErrors. 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).

The proposal PR outlines scenarios where this change may not be backward-incompatible. However, think they are rare coding patterns and anticipate low interoperability risk.

Previous discussions
Previously brought up in a WHATNOT (2025-02-06) with some subtle positive signals of interest while raising compat concerns.

[asutherland]

This is what the referenced minutes say @smaug---- said:

olli: there was an internal thread about this, and Yoav said it sounds like a good idea. a bit worried about compat, but if chromium is willing to try it

I agree with this sentiment that this seems like a good thing as long as there isn't significant webcompat impact. I appreciate the effort taking in the webidl PR to characterize what could break and providing a github search showing the limited number of cases found there.

I also agree with the rationale there that quota exceeded errors should be rare, mitigating potential impact. Also, I would hand-wave that:

• It's very common that error handling for these cases was made as a best-effort but actually is broken anyways.
• In my personal JS code experience my logic cared about whether it was looking at a JS Error or a DOM Exception and that impacted for example extracting filename (Gecko non-standard ExceptionMembers field vs fileName (non-standard SpiderMonkey-ism) where deviations ideally just result in an undefined value being extracted rather than an exception being thrown.