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
<https://github.com/whatwg/webidl/pull/1465>
Specification
https://github.com/whatwg/webidl/pull/1465
<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
<https://github.com/mozilla/standards-positions/issues/1223>)
WebKit: Pending
(https://github.com/WebKit/standards-positions/issues/468
<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
<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/afd9ed04-bcc0-4713-95c6-a7e1e90fa307%40gmail.com.
