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? > > -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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdPLTWx4a-5z7USY6CjVC8smwYYaq-%2ByGKe9w99HKieeg%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/CAL5BFfXOwYLx2jx%2B67MC532_d40p0giB3xA0n8sUFrsC0XUzsg%40mail.gmail.com.
