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/5c732e05-9adb-43d8-b8d8-10512643214dn%40chromium.org.

Reply via email to