Update QuotaExceededError to a DOMException derived interface

[ayuishii]

WebKittens

@annevk

Title of the proposal

Update QuotaExceededError to a DOMException derived interface

URL to the spec

https://webidl.spec.whatwg.org/#idl-DOMException

URL to the spec's repository

https://github.com/whatwg/webidl

Issue Tracker URL

No response

Explainer URL

whatwg/webidl#1465

TAG Design Review URL

No response

Mozilla standards-positions issue URL

whatwg/html#10972

WebKit Bugzilla URL

No response

Radar URL

No response

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.

[rniwa]

cc @szewai

[annevk]

Any use cases beyond that one API cited in the PR?

[szewai]

I have the same question as @annevk.

For the example, there is a token limit for each summarize request, so it's easy to define quota and requested. I am not sure it's the same case for the other listed APIs. If most of them don't need to provide this information, maybe it is not worth risking breaking existing clients.

[domenic]

There are clear quotas and requested values for many (maybe all?) of the other cases. For some it doesn't necessarily make sense to expose for privacy reasons, and for others it might be theoretically a good idea but not necessarily a feature developers are clamoring for. Here's a quick skim of some cases I found (non-exhaustive):

• The https://fs.spec.whatwg.org/ cases are dependent on the storage quota. This would be pretty useful, and would avoid having the web developer need to estimate the exact translation from their input bytes to a requested number (including, e.g., padding), and would avoid a roundtrip to (await navigator.storage.estimate()).quota.
• https://wicg.github.io/handwriting-recognition/ is an interesting case: "If creating a handwriting recognizer would cause the user agent to exceed its limit for total number of active recognizer, "QuotaExceededError"." This could give clarity into how many recognizers are allowed, which might be useful, but, that might be a global limit which we wouldn't necessarily want to reveal.
• https://w3c.github.io/webcrypto/#Crypto-method-getRandomValues is pretty clear: we could easily fill in byteLength for requested and 65536 for quota
• I don't know much about MSE, but https://w3c.github.io/media-source/#sourcebuffer-prepare-append seems like a case where giving more clear info to the web developer would be beneficial

In general, I think this pattern is a good one to have in the platform, for the reasons explained in https://github.com/webmachinelearning/writing-assistance-apis/blob/8e551408a57d79afc6b32c88597ef5728febd30b/README.md#too-large-inputs: instead of encouraging code like

const usage = await measureUsage(input);
const quota = await getQuota();
if (usage < quota) {
  await sendInput(input);
} else {
  console.log(`${usage} > ${quota}, no good, reduce your input by ${(1 - usage/quota)*100)}%!!`);
}

which requires 3 round trips to whatever the backing system is, we can encourage code like

try {
  await sendInput(input);
} catch (e) {
  if (e.name !== "QuotaExceededError") { throw e; }
  console.log(`${e.requested} > ${e.quota}, no good, reduce your input by ${(1 - e.requested/e.quota)*100)}%!!`);
}

which requires 1 round trip to the backing system.