Contact emailsshase...@chromium.org Explainerhttps://github.com/shaseley/abort-signal-any/blob/main/README.md
Specificationhttps://dom.spec.whatwg.org/#dom-abortsignal-any https://wicg.github.io/scheduling-apis/#dom-tasksignal-any (TaskSignal specialization) Design docs https://docs.google.com/document/d/1LvmsBLV85p-PhSGvTH-YwgD6onuhh1VXLg8jPlH32H4/edit#heading=h.xp6e50wyimb4 Summary 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 This intent also includes TaskSignal.any(), which is a specialization of AbortSignal.any() (TaskSignal inherits from AbortSignal) for https://wicg.github.io/scheduling-apis/. The specialization behaves the same for abort, but returns a TaskSignal with the priority bit initialized from the additional optional parameter. TaskSignal is only implemented in Chromium, and this is a small addition to keep the API in sync with the base class. Blink componentBlink>DOM <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EDOM> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/737 TAG review statusIssues addressed Risks 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 Probably "mildly positive": - 4 stars on implementation bug (crbug.com/13233910) - Discussion/motivation on DOM issue ( https://github.com/whatwg/dom/issues/920 - A couple libraries implement something similar ( https://www.reddit.com/r/javascript/comments/ve96pn/abortcontroller_is_your_friend/ ) *Other signals*: Implemented in Node.js: https://github.com/nodejs/node/pull/47821 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)?Yes Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ?Yes Flag name--enable-blink-features=AbortSignalAny Requires code in //chrome?False Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1323391 Estimated 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/5202879349522432 Links to previous Intent discussionsIntent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ2siKxHbAB3YL%2BX1%2BNvRvOXGYKCc_Ybyq7azqd-_AS4rg%40mail.gmail.com 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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ3%3DYz%3Di2cdJJUQVc4Uxh1Up2AaWj1Uw50qHBjiU_8PP6w%40mail.gmail.com.
