Intent to Ship: AbortSignal.any()
Scott Haseley
Contact emails
shas...@chromium.orgExplainer
https://github.com/shaseley/abort-signal-any/blob/main/README.mdSpecification
https://dom.spec.whatwg.org/#dom-abortsignal-anyDesign docs
https://docs.google.com/document/d/1LvmsBLV85p-PhSGvTH-YwgD6onuhh1VXLg8jPlH32H4/edit#heading=h.xp6e50wyimb4Summary
AbortSignal.any(signals) returns a signal that is aborted when any of the source signals are aborted. Developers can use this to combine independent abort sources, e.g. timeouts specified with AbortSignal.timeout() and signals associated with user input, and pass them to async APIs like fetch().
Comments
Blink component
Blink>DOMTAG review
https://github.com/w3ctag/design-reviews/issues/737TAG review status
Issues addressedRisks
Interoperability and Compatibility
There's a slight compat risk resulting from spec changes associated with the new feature.
Signals could previously be combined (in specs) similarly using the "follow" algorithm, which was replaced with a new algorithm for creating a dependent signal. The new algorithm changes the order the abort event is propagated between source and dependent signals, which was done to optimize memory management (one of the API goals) and limit complexity. This is observable in two ways: 1. In fetch, `new Request(url, {signal})` and `request.clone()` made a "copy" of the input signal using "follow", so the relative order of 'abort' events between 'signal' and `request.signal` can change. For example: ``` // Previously, handler2 ran before handler1, if the signal is aborted. signal.addEventListener('abort', handler1); const r = new Request(url, {signal}); r.signal.addEventListener('abort', handler2); ``` `clone()` is similar (one WPT test was changed for the new expectation). 2. Our cache.addAll() implementation had an unspecced use of "follow" that could result in 'abort' events firing when they shouldn't have. This was fixed. The risk seems low here, and we didn't think changing the API implementation to ensure this order was worth the complexity/optimization limitations. The feature can be disabled via kill switch (AbortSignalAny) if necessary.
Gecko: Positive (https://github.com/mozilla/standards-positions/issues/774)
WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=256176)
Web developers: No signals
Other signals:
Ergonomics
This is designed to be used with other AbortSignal APIs (AbortController and AbortSignal.timeout), and improves ergonomics of handling multiple signals.
Activation
The feature would benefit from a polyfill.
Security
None. https://github.com/shaseley/abort-signal-any/blob/main/tag-questionnaire.md
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?
See compat section.
Debuggability
Basic support only.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
YesIs this feature fully tested by web-platform-tests?
YesFlag name
--enable-blink-features=AbortSignalAnyRequires code in //chrome?
FalseTracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1323391Estimated milestones
| Shipping on desktop | 116 |
| Shipping on Android | 116 |
| Shipping on WebView | 116 |
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).
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5202879349522432Links to previous Intent discussions
Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ2siKxHbAB3YL%2BX1%2BNvRvOXGYKCc_Ybyq7azqd-_AS4rg%40mail.gmail.com
Mike West
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ3%3DYz%3Di2cdJJUQVc4Uxh1Up2AaWj1Uw50qHBjiU_8PP6w%40mail.gmail.com.
Yoav Weiss
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdPLTWx4a-5z7USY6CjVC8smwYYaq-%2ByGKe9w99HKieeg%40mail.gmail.com.
Rick Byers
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXOwYLx2jx%2B67MC532_d40p0giB3xA0n8sUFrsC0XUzsg%40mail.gmail.com.
Scott Haseley
LGTM3Thanks for ensuring the behavior changes are behind a kill-switch!RickOn Wed, May 31, 2023, 5:10 a.m. Yoav Weiss <yoav...@chromium.org> wrote:LGTM2 (% Mike's question)On Wed, May 31, 2023 at 5:04 AM Mike West <mk...@chromium.org> wrote:LGTM1.The risks you point to seem minor, and following along with Safari's implementation makes it more likely that we can land the feature in a way that sticks. Do you have insight into Mozilla's implementation progress?