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 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/6bf5d5be-b2ff-4270-b3b8-116b7e752bc5n%40chromium.org.
