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?
-mike On Fri, May 26, 2023 at 12:47 AM Scott Haseley <shase...@chromium.org> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ3%3DYz%3Di2cdJJUQVc4Uxh1Up2AaWj1Uw50qHBjiU_8PP6w%40mail.gmail.com?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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdPLTWx4a-5z7USY6CjVC8smwYYaq-%2ByGKe9w99HKieeg%40mail.gmail.com.
