Thanks! On Wed, May 31, 2023 at 7:21 AM Rick Byers <rby...@chromium.org> wrote:
> LGTM3 > > Thanks for ensuring the behavior changes are behind a kill-switch! > > Rick > > On Wed, May 31, 2023, 5:10 a.m. Yoav Weiss <yoavwe...@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? >>> >> I don't. The tracking bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1830781, but it doesn't have much activity yet. Re: Safari, I just looked at their implementation and they haven't yet replaced "follow" with the new algorithm. I can follow up / file a separate bug for the fetch integration, or maybe wait until this rolls out and sticks? -mike >>> >>> >>> On Fri, May 26, 2023 at 12:47 AM Scott Haseley <shase...@chromium.org> >>> wrote: >>> >>>> Contact emailsshase...@chromium.org >>>> >>>> Explainer >>>> https://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 bug >>>> https://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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXOwYLx2jx%2B67MC532_d40p0giB3xA0n8sUFrsC0XUzsg%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/CAKXGoJ31nKNK9gSAxmNRoRmJn4m5HRc2%2BuFK8ERPgDJxgk%2BTeQ%40mail.gmail.com.
