Re: [blink-dev] Intent to Ship: Omnibox Prerendering

[Yoav Weiss]

I agree with Domenic that it's great to see this kind of feature, that was
traditionally unspecified, getting some clearer developer visibility and a
spec. While there may still be missing pieces, this seems like a good
start. I'm looking forward to further spec discussions that would hopefully
lead to convergence and better interop.

On Fri, Feb 11, 2022 at 11:39 PM Domenic Denicola 
wrote:

>
>
> On Fri, Feb 11, 2022 at 11:53 AM Olli Pettay 
> wrote:
>
>> FWIW, the comment in the HTML spec triage was positive feedback to have a
>> spec for this.
>> The current spec proposal clearly is missing still quite a few cases (is
>> the idea really that one can use BroadcastChannel with prerendered page?
>> and the webidl annotation behaves rather oddly)
>> So it is surprising to see this shipping already now.
>>
>
> Thanks for chiming in, Olli!
>
> I have a rather different take. As the team's spec mentor, I'm impressed
> with the spec work the team has done, on taking what most other browsers
> have treated as a not-to-be-specified user agent UI feature, and turning it
> into something much more rigorous and developer-friendly. For example:
>
>- The careful auditing of all APIs to see how they should behave in
>prerendering.
>- Introducing a well-specified Sec-Purpose: prefetch header, instead
>of the unspecified X-moz: prefetch or X-Purpose: preview headers.
>- Considering how to handle edge cases such as redirects, 204s,
>Content-Disposition: attachment, or pages that do client-side navigation
>while being prerendered.
>
> I think there's definitely still work to be done, as we try to move from
> the current world where every browser does something different into one
> that's more fully predictable for web developers. But I think this is
> similar to other features, like bfcache, where for many years the
> heuristics and rules used were unspecified (e.g. Cache-Control, unload
> handlers, BroadcastChannel), and then we've started a slow convergence
> process as browsers start to care more about interoperability.
>
> We can definitely tweak things, like Olli's example of BroadcastChannel,
> over time and as other browsers indicate willingness to converge.
>

One potential problem with that approach is that sites may grow to rely on
that existence of e.g. BroadcastChannel and may break when we take that
away.
I don't think that's a risk for the current I2S, as developers are not
aware that the page is being prerendered outside of the page itself, so the
chances of them trying to communicate with it are low.
But that can be a risk for the speculation rules based API, which would be
good to mitigate.


> But like with bfcache, there may be cases where browsers intentionally
> differ. What the team has done as a starting point is document their
> currently-implemented behaviors, and I imagine some of those will become
> implementation-defined (if browsers decide to differentiate on a given
> feature); some will stay as is (if all browsers agree Chromium's
> initially-proposed approach is best); and some will be changed (if other
> browsers convince us that their approach is better). Personally, I
> envisioned the process of moving chunks of the spec from
> WICG/nav-speculation into the HTML Standard as the best way to have these
> conversations, which is why I was excited to get positive feedback from
> Olli and others on the HTML triage call.
>
> Is there some compat risk from such changes? Well, they're observable, so
> technically yes. But my judgment is that the compat risks are
> minimal---especially for URL-bar triggered prerendering, which cannot be
> initiated by the web page and thus is very hard to take a dependency on.
>
> (As for the Web IDL extended attribute, I'd love to hear more about
> "behaves rather oddly", especially on the issue tracker
> .)
>
> Hope this helps!
>
>
>>
>> -Olli
>>
>> On Fri, Feb 11, 2022 at 7:20 AM Kouhei Ueno  wrote:
>>
>>> Contact emails
>>>
>>> loading-...@chromium.org, noam.j.rosent...@gmail.com
>>>
>>> Component
>>>
>>> Internals>Preload>Prerender
>>>
>>> Explainer
>>>
>>>
>>> https://github.com/WICG/nav-speculation/blob/main/ua-initiated-prerendering.md
>>>
>>> Spec
>>>
>>> https://wicg.github.io/nav-speculation/prerendering.html
>>> Discussion about upstreaming into HTML and elsewhere: whatwg/html#7533
>>> 
>>>
>>> The corresponding TAG review is w3ctag/design-reviews#667
>>> . (That review was
>>> for speculation-rules triggered prerendering, which has a superset of the
>>> considerations for omnibox-triggered prerendering.)
>>>
>>> Summary
>>>
>>> We would like to ship omnibox (i.e., URL bar) prerendering. With this
>>> feature, Chrome will start prerendering the high-confidence omnibox
>>> autocomplete suggestions. Chrome is currently prefetching resources for
>>> high-confidence suggestions using 

Re: [blink-dev] Intent to Ship: Omnibox Prerendering

[Domenic Denicola]

On Fri, Feb 11, 2022 at 11:53 AM Olli Pettay  wrote:

> FWIW, the comment in the HTML spec triage was positive feedback to have a
> spec for this.
> The current spec proposal clearly is missing still quite a few cases (is
> the idea really that one can use BroadcastChannel with prerendered page?
> and the webidl annotation behaves rather oddly)
> So it is surprising to see this shipping already now.
>

Thanks for chiming in, Olli!

I have a rather different take. As the team's spec mentor, I'm impressed
with the spec work the team has done, on taking what most other browsers
have treated as a not-to-be-specified user agent UI feature, and turning it
into something much more rigorous and developer-friendly. For example:

   - The careful auditing of all APIs to see how they should behave in
   prerendering.
   - Introducing a well-specified Sec-Purpose: prefetch header, instead of
   the unspecified X-moz: prefetch or X-Purpose: preview headers.
   - Considering how to handle edge cases such as redirects, 204s,
   Content-Disposition: attachment, or pages that do client-side navigation
   while being prerendered.

I think there's definitely still work to be done, as we try to move from
the current world where every browser does something different into one
that's more fully predictable for web developers. But I think this is
similar to other features, like bfcache, where for many years the
heuristics and rules used were unspecified (e.g. Cache-Control, unload
handlers, BroadcastChannel), and then we've started a slow convergence
process as browsers start to care more about interoperability.

We can definitely tweak things, like Olli's example of BroadcastChannel,
over time and as other browsers indicate willingness to converge. But like
with bfcache, there may be cases where browsers intentionally differ. What
the team has done as a starting point is document their
currently-implemented behaviors, and I imagine some of those will become
implementation-defined (if browsers decide to differentiate on a given
feature); some will stay as is (if all browsers agree Chromium's
initially-proposed approach is best); and some will be changed (if other
browsers convince us that their approach is better). Personally, I
envisioned the process of moving chunks of the spec from
WICG/nav-speculation into the HTML Standard as the best way to have these
conversations, which is why I was excited to get positive feedback from
Olli and others on the HTML triage call.

Is there some compat risk from such changes? Well, they're observable, so
technically yes. But my judgment is that the compat risks are
minimal---especially for URL-bar triggered prerendering, which cannot be
initiated by the web page and thus is very hard to take a dependency on.

(As for the Web IDL extended attribute, I'd love to hear more about
"behaves rather oddly", especially on the issue tracker
.)

Hope this helps!


>
> -Olli
>
> On Fri, Feb 11, 2022 at 7:20 AM Kouhei Ueno  wrote:
>
>> Contact emails
>>
>> loading-...@chromium.org, noam.j.rosent...@gmail.com
>>
>> Component
>>
>> Internals>Preload>Prerender
>>
>> Explainer
>>
>>
>> https://github.com/WICG/nav-speculation/blob/main/ua-initiated-prerendering.md
>>
>> Spec
>>
>> https://wicg.github.io/nav-speculation/prerendering.html
>> Discussion about upstreaming into HTML and elsewhere: whatwg/html#7533
>> 
>>
>> The corresponding TAG review is w3ctag/design-reviews#667
>> . (That review was
>> for speculation-rules triggered prerendering, which has a superset of the
>> considerations for omnibox-triggered prerendering.)
>>
>> Summary
>>
>> We would like to ship omnibox (i.e., URL bar) prerendering. With this
>> feature, Chrome will start prerendering the high-confidence omnibox
>> autocomplete suggestions. Chrome is currently prefetching resources for
>> high-confidence suggestions using No-state Prefetch
>> ,
>> but with this feature we will be further processing the webpage, including
>> the DOM tree construction and script execution.
>>
>> While this is a user agent feature, this is an observable change to the
>> prerendered websites. This prerendering affects how the prerendered pages
>> are processed. The website gets loaded before the navigation is committed,
>> and the side-effects are delayed until activation (the actual navigation to
>> the website was committed). We also would like to add a simple APIs
>> (document.prerendering) to directly let the website know that it is being
>> prerendered and when it was activated (prerenderingchange event,
>> performance.activationStart timing).
>>
>> Note that we are not shipping speculation rules triggered prerender2 (I2E
>> extension
>> )
>> with this I2S, 

Re: [blink-dev] Intent to Ship: Omnibox Prerendering

[Olli Pettay]

On 2/11/22 07:20, Kouhei Ueno wrote:

Contact emails

loading-...@chromium.org , 
noam.j.rosent...@gmail.com 


Component

Internals>Preload>Prerender


Explainer

https://github.com/WICG/nav-speculation/blob/main/ua-initiated-prerendering.md 




Spec

https://wicg.github.io/nav-speculation/prerendering.html
Discussion about upstreaming into HTML and elsewhere: whatwg/html#7533 




The corresponding TAG review is w3ctag/design-reviews#667 . (That review was for 
speculation-rules triggered prerendering, which has a superset of the considerations for omnibox-triggered prerendering.)



Summary

We would like to ship omnibox (i.e., URL bar) prerendering. With this feature, Chrome will start prerendering the high-confidence omnibox autocomplete 
suggestions. Chrome is currently prefetching resources for high-confidence suggestions using No-state Prefetch 
, but with this feature we will be further processing the webpage, including the 
DOM tree construction and script execution.



While this is a user agent feature, this is an observable change to the prerendered websites. This prerendering affects how the prerendered pages are 
processed. The website gets loaded before the navigation is committed, and the side-effects are delayed until activation (the actual navigation to the 
website was committed). We also would like to add a simple APIs (document.prerendering) to directly let the website know that it is being prerendered 
and when it was activated (prerenderingchange event, performance.activationStart timing).



Note that we are not shipping speculation rules triggered prerender2 (I2E extension 
) with this I2S, which allows web pages to prerender other web 
pages. We will come back (hopefully soon) with a separate I2S. For details about our web exposed changes shipping plan, please consult this doc: 
Interoperability Roadmap for Shipping Prerender2 Incrementally .



Link to “Intent to Prototype” blink-dev discussion

We don’t have a corresponding “Intent to Prototype”. This was implemented as a variation of other prerender2 triggers (Speculation rules I2E 
).



Is this feature supported on all six Blink platforms (Windows, Mac, Linux, 
Chrome OS, Android, and Android WebView)?

We plan to roll out omnibox-triggered prerendering from Android platforms, where we already have the MPArch coverage. Eventually, we will enable this 
on all platforms.



Demo link

For a demo of prerendering generally, and its effect on websites, https://prerender2-specrules.glitch.me/ 
shows it triggered by speculation rules (which are not part of this Intent).



Instruction: Demonstration of URL-bar-triggered Omnibox prerendering 



Demo page: https://omnibox-prerender.glitch.me/ 



Debuggability

We are actively talking to the devtools team about adding general Prerender support to it [metabug 
]. The MVP is to expose the prerendered page status in the panel so web developers can 
know if they finished successfully, or they couldn’t proceed due to its feature restrictions.



We currently don’t have a plan to add devtools support specifically for the 
omnibox prerender trigger (your thoughts are welcome!).


Measurement

We have implemented UseCounters [cs 
] to monitor the usage 
of the properties added by this I2S.



Risks

Compatibility

There is a non-zero chance that the behavior of the prerendered sites can be broken. The prerendered pages are loaded and rendered before user 
actually navigates to the websites, so there will be some number of prerenders that are false positives, which end up not being used. The websites 
will observe the requests, and can run some JavaScript, which can have side effects.



That said, triggering a prerender from the address bar isn’t an entirely new behavior. Chrome used to have a prerendering feature a long while ago 
. A similar behavior is also present in other browsers (e.g. “Preload Top Hit” feature 
in Safari).


For omnibox 

Re: [blink-dev] Intent to Ship: Omnibox Prerendering

[Olli Pettay]

FWIW, the comment in the HTML spec triage was positive feedback to have a
spec for this.
The current spec proposal clearly is missing still quite a few cases (is
the idea really that one can use BroadcastChannel with prerendered page?
and the webidl annotation behaves rather oddly)
So it is surprising to see this shipping already now.

-Olli

On Fri, Feb 11, 2022 at 7:20 AM Kouhei Ueno  wrote:

> Contact emails
>
> loading-...@chromium.org, noam.j.rosent...@gmail.com
>
> Component
>
> Internals>Preload>Prerender
>
> Explainer
>
>
> https://github.com/WICG/nav-speculation/blob/main/ua-initiated-prerendering.md
>
> Spec
>
> https://wicg.github.io/nav-speculation/prerendering.html
> Discussion about upstreaming into HTML and elsewhere: whatwg/html#7533
> 
>
> The corresponding TAG review is w3ctag/design-reviews#667
> . (That review was
> for speculation-rules triggered prerendering, which has a superset of the
> considerations for omnibox-triggered prerendering.)
>
> Summary
>
> We would like to ship omnibox (i.e., URL bar) prerendering. With this
> feature, Chrome will start prerendering the high-confidence omnibox
> autocomplete suggestions. Chrome is currently prefetching resources for
> high-confidence suggestions using No-state Prefetch
> , but
> with this feature we will be further processing the webpage, including the
> DOM tree construction and script execution.
>
> While this is a user agent feature, this is an observable change to the
> prerendered websites. This prerendering affects how the prerendered pages
> are processed. The website gets loaded before the navigation is committed,
> and the side-effects are delayed until activation (the actual navigation to
> the website was committed). We also would like to add a simple APIs
> (document.prerendering) to directly let the website know that it is being
> prerendered and when it was activated (prerenderingchange event,
> performance.activationStart timing).
>
> Note that we are not shipping speculation rules triggered prerender2 (I2E
> extension
> )
> with this I2S, which allows web pages to prerender other web pages. We will
> come back (hopefully soon) with a separate I2S. For details about our web
> exposed changes shipping plan, please consult this doc: Interoperability
> Roadmap for Shipping Prerender2 Incrementally
> 
> .
>
> Link to “Intent to Prototype” blink-dev discussion
>
> We don’t have a corresponding “Intent to Prototype”. This was implemented
> as a variation of other prerender2 triggers (Speculation rules I2E
> 
> ).
>
> Is this feature supported on all six Blink platforms (Windows, Mac, Linux,
> Chrome OS, Android, and Android WebView)?
>
> We plan to roll out omnibox-triggered prerendering from Android platforms,
> where we already have the MPArch coverage. Eventually, we will enable this
> on all platforms.
>
> Demo link
>
> For a demo of prerendering generally, and its effect on websites,
> https://prerender2-specrules.glitch.me/ shows it triggered by speculation
> rules (which are not part of this Intent).
>
> Instruction: Demonstration of URL-bar-triggered Omnibox prerendering
> 
>
> Demo page: https://omnibox-prerender.glitch.me/
>
> Debuggability
>
> We are actively talking to the devtools team about adding general
> Prerender support to it [metabug
> ]. The MVP
> is to expose the prerendered page status in the panel so web developers can
> know if they finished successfully, or they couldn’t proceed due to its
> feature restrictions.
>
> We currently don’t have a plan to add devtools support specifically for
> the omnibox prerender trigger (your thoughts are welcome!).
>
> Measurement
>
> We have implemented UseCounters [cs
> ]
> to monitor the usage of the properties added by this I2S.
>
> Risks
>
> Compatibility
>
> There is a non-zero chance that the behavior of the prerendered sites can
> be broken. The prerendered pages are loaded and rendered before user
> actually navigates to the websites, so there will be some number of
> prerenders that are false positives, which end up not being used. The
> websites will observe the requests, and can run some JavaScript, which can
> have side effects.
>
> That said, triggering a prerender from the address bar isn’t an entirely
> new behavior. Chrome used to have a prerendering feature a 

Re: [blink-dev] Intent to Ship: AbortSignal.prototype.throwIfAborted

[Chris Harrelson]

LGTM3

On Fri, Feb 11, 2022 at 8:28 AM Yoav Weiss  wrote:

> LGTM2 - thanks for helping us catching up!
>
> On Fri, Feb 11, 2022 at 4:57 PM Mike Taylor 
> wrote:
>
>> LGTM1 - seems like a useful feature and good to see that Gecko and WebKit
>> have already shipped.
>>
>> On 2/10/22 5:54 PM, Scott Haseley wrote:
>>
>> Contact emails shase...@chromium.org
>>
>> Explainer Discussion: https://github.com/whatwg/dom/issues/927
>> Examples:
>> https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/throwIfAborted
>>
>> Specification https://dom.spec.whatwg.org/#dom-abortsignal-throwifaborted
>>
>> Summary
>>
>> Throws an AbortSignal's reason if the signal is aborted. This convenience
>> method can be used by signal-handling functions to check a signal's abort
>> status and propagate the abort reason, e.g. after async operations that
>> might change a signal's state.
>>
>> Blink component Blink>DOM
>> 
>>
>> TAG review N/A: the feature has been merged into the DOM standard and
>> has been shipped in at least one other browser, in line with the criteria
>> in
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/naqmDmy1iM8/m/lQAJ17CRAQAJ
>> .
>>
>> TAG review status Not applicable
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> Low risk. This feature is already part of the DOM standard, has web
>> platform tests, and is implemented by Safari and Firefox. We'll improve
>> eventual interop by shipping this feature.
>>
>> Gecko: Shipped/Shipping (
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1745372)
>>
>> WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=234127)
>>
>> Web developers: Positive. Minor positive feedback (likes) from
>> announcement tweets:
>> - Safari: https://twitter.com/chris_dumez/status/1469566206516424704
>> - Node: https://twitter.com/simonplend/status/1487053107720859648 and
>> https://twitter.com/jasnell/status/1466093594129756166
>>
>> Other signals:
>>
>> Ergonomics
>>
>> None; this feature is an ergonomic improvement for AbortSignal users.
>>
>> Activation
>>
>> The feature has already been implemented in both Safari and Firefox, but
>> it would benefit from a polyfill for use in older browser versions.
>>
>> Security
>>
>> None.
>>
>> Debuggability
>>
>> Basic tooling only, i.e. autocomplete support for the new AbortSignal
>> method will be provided.
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ? Yes (
>> https://wpt.fyi/results/dom/abort/event.any.html?label=master=experimental=dom%2Fabort
>> )
>>
>> Flag name --enable-blink-features=AbortSignalThrowIfAborted
>>
>> Requires code in //chrome? False
>>
>> Tracking bug
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1273458
>>
>> Launch bug https://bugs.chromium.org/p/chromium/issues/detail?id=1290443
>>
>> Measurement UseCounter: AbortSignalThrowIfAborted
>>
>> Sample links
>> https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/throwIfAborted#examples
>>
>> Estimated milestones
>> DevTrial on desktop 100
>> DevTrial on android 100
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5029737100476416
>>
>> Links to previous Intent discussions Intent to prototype:
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ3tUkTGZ1VBQm4139zL0n%3De-DO5emVpZE3ukya4Akyu2w%40mail.gmail.com
>> 
>>
>>
>> This intent message was generated by Chrome Platform Status
>> .
>> --
>> 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/CAKXGoJ1w2WYK4X6fA7V4C0xNJBetNb%3D%2BCMywobhzzc9q9xSRxg%40mail.gmail.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/469859d1-1f5a-b3f9-f725-26563c112bb7%40chromium.org
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop 

Re: [blink-dev] Intent to Ship: AbortSignal.prototype.throwIfAborted

[Yoav Weiss]

LGTM2 - thanks for helping us catching up!

On Fri, Feb 11, 2022 at 4:57 PM Mike Taylor  wrote:

> LGTM1 - seems like a useful feature and good to see that Gecko and WebKit
> have already shipped.
>
> On 2/10/22 5:54 PM, Scott Haseley wrote:
>
> Contact emails shase...@chromium.org
>
> Explainer Discussion: https://github.com/whatwg/dom/issues/927
> Examples:
> https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/throwIfAborted
>
> Specification https://dom.spec.whatwg.org/#dom-abortsignal-throwifaborted
>
> Summary
>
> Throws an AbortSignal's reason if the signal is aborted. This convenience
> method can be used by signal-handling functions to check a signal's abort
> status and propagate the abort reason, e.g. after async operations that
> might change a signal's state.
>
> Blink component Blink>DOM
> 
>
> TAG review N/A: the feature has been merged into the DOM standard and has
> been shipped in at least one other browser, in line with the criteria in
> https://groups.google.com/a/chromium.org/g/blink-dev/c/naqmDmy1iM8/m/lQAJ17CRAQAJ
> .
>
> TAG review status Not applicable
>
> Risks
>
> Interoperability and Compatibility
>
> Low risk. This feature is already part of the DOM standard, has web
> platform tests, and is implemented by Safari and Firefox. We'll improve
> eventual interop by shipping this feature.
>
> Gecko: Shipped/Shipping (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1745372)
>
> WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=234127)
>
> Web developers: Positive. Minor positive feedback (likes) from
> announcement tweets:
> - Safari: https://twitter.com/chris_dumez/status/1469566206516424704
> - Node: https://twitter.com/simonplend/status/1487053107720859648 and
> https://twitter.com/jasnell/status/1466093594129756166
>
> Other signals:
>
> Ergonomics
>
> None; this feature is an ergonomic improvement for AbortSignal users.
>
> Activation
>
> The feature has already been implemented in both Safari and Firefox, but
> it would benefit from a polyfill for use in older browser versions.
>
> Security
>
> None.
>
> Debuggability
>
> Basic tooling only, i.e. autocomplete support for the new AbortSignal
> method will be provided.
>
> Is this feature fully tested by web-platform-tests
> 
> ? Yes (
> https://wpt.fyi/results/dom/abort/event.any.html?label=master=experimental=dom%2Fabort
> )
>
> Flag name --enable-blink-features=AbortSignalThrowIfAborted
>
> Requires code in //chrome? False
>
> Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1273458
>
> Launch bug https://bugs.chromium.org/p/chromium/issues/detail?id=1290443
>
> Measurement UseCounter: AbortSignalThrowIfAborted
>
> Sample links
> https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/throwIfAborted#examples
>
> Estimated milestones
> DevTrial on desktop 100
> DevTrial on android 100
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5029737100476416
>
> Links to previous Intent discussions Intent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ3tUkTGZ1VBQm4139zL0n%3De-DO5emVpZE3ukya4Akyu2w%40mail.gmail.com
> 
>
>
> This intent message was generated by Chrome Platform Status
> .
> --
> 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/CAKXGoJ1w2WYK4X6fA7V4C0xNJBetNb%3D%2BCMywobhzzc9q9xSRxg%40mail.gmail.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/469859d1-1f5a-b3f9-f725-26563c112bb7%40chromium.org
> 
> .
>

-- 
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 

Re: [blink-dev] Intent to Ship: AbortSignal.prototype.throwIfAborted

[Mike Taylor]

LGTM1 - seems like a useful feature and good to see that Gecko and 
WebKit have already shipped.


On 2/10/22 5:54 PM, Scott Haseley wrote:



Contact emails

shase...@chromium.org


Explainer

Discussion: https://github.com/whatwg/dom/issues/927
Examples: 
https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/throwIfAborted



Specification

https://dom.spec.whatwg.org/#dom-abortsignal-throwifaborted


Summary

Throws an AbortSignal's reason if the signal is aborted. This 
convenience method can be used by signal-handling functions to check a 
signal's abort status and propagate the abort reason, e.g. after async 
operations that might change a signal's state.



Blink component

Blink>DOM 




TAG review

N/A: the feature has been merged into the DOM standard and has been 
shipped in at least one other browser, in line with the criteria in 
https://groups.google.com/a/chromium.org/g/blink-dev/c/naqmDmy1iM8/m/lQAJ17CRAQAJ.



TAG review status

Not applicable


Risks


Interoperability and Compatibility

Low risk. This feature is already part of the DOM standard, has web 
platform tests, and is implemented by Safari and Firefox. We'll 
improve eventual interop by shipping this feature.



Gecko: Shipped/Shipping 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1745372)


WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=234127)

Web developers: Positive. Minor positive feedback (likes) from 
announcement tweets:

- Safari: https://twitter.com/chris_dumez/status/1469566206516424704
- Node: https://twitter.com/simonplend/status/1487053107720859648 and 
https://twitter.com/jasnell/status/1466093594129756166


Other signals:


Ergonomics

None; this feature is an ergonomic improvement for AbortSignal users.


Activation

The feature has already been implemented in both Safari and Firefox, 
but it would benefit from a polyfill for use in older browser versions.



Security

None.


Debuggability

Basic tooling only, i.e. autocomplete support for the new AbortSignal 
method will be provided.



Is this feature fully tested by web-platform-tests

?

Yes 
(https://wpt.fyi/results/dom/abort/event.any.html?label=master=experimental=dom%2Fabort 
)



Flag name

--enable-blink-features=AbortSignalThrowIfAborted


Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1273458


Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1290443


Measurement

UseCounter: AbortSignalThrowIfAborted


Sample links

https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/throwIfAborted#examples


Estimated milestones

DevTrial on desktop 100

DevTrial on android 100


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5029737100476416


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ3tUkTGZ1VBQm4139zL0n%3De-DO5emVpZE3ukya4Akyu2w%40mail.gmail.com 




This intent message was generated by Chrome Platform Status 
.

--
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/CAKXGoJ1w2WYK4X6fA7V4C0xNJBetNb%3D%2BCMywobhzzc9q9xSRxg%40mail.gmail.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/469859d1-1f5a-b3f9-f725-26563c112bb7%40chromium.org.

Re: [blink-dev] Intent to Extend Experiment: Storage Foundation API

[Mike Taylor]

LGTM3 - agree with Mike

On 2/11/22 5:17 AM, Yoav Weiss wrote:

LGTM2 under the same conditions, for one last extension here.



On Fri, Feb 11, 2022 at 11:14 AM Mike West  wrote:

Hey Emanuel,

API owners discussed this intent this week and the week before,
with a fair amount of skepticism around the length of the
experimentation (April 2021 (90) - May 2022 (101)), and the value
of continuing this experiment in light of what looks like
reasonable alignment from our colleagues in WebKit and Gecko on
the Access Handles proposal which y'all are working through in
parallel. With that in mind, the best path forward would be to let
this experiment expire rather than extending it. Unfortunately, it
appears that some miscommunication led a partner to begin relying
on this API in ways that make it difficult for us to simply remove
support. This puts us in a bit of a pickle.

I'd like to ensure that we don't end up in this situation again in
3 months if we extend this OT to give the partner time to migrate
off of Storage Foundation. I think we have solid commitments from
them that they'll be able to shift onto Access Handles in the
timeframe we're discussing, and I think we can strengthen that
encouragement by allowing them to extend their OT tokens once, and
then disabling new signups for the OT to ensure that new partners
don't accidentally land on this instead of Access Handles. That's
a compromise that seems to me to minimize the incremental risk of
burn-in, while allowing us to remove this API from the platform
without user-visible breakage. But it's an unusual extension, so I
don't think a single LGTM is sufficient to approve it.

LGTM1 to extend the trial to 101 _and_ disable new signups or
renewals. Ideally, the partner can complete their migration before
101, in which case we can end the trial earlier. I'd appreciate
other API owners weighing in.

-mike


On Tue, Feb 1, 2022 at 4:55 PM Emanuel Krivoy
 wrote:

Hi Chris,

Replies inline as well:

Is it accurate to say then that there hasn't been
substantial use on sites recently? Or are they using it
generally but just haven't run the set of tests yet?


The latter, Photoshop Web used Storage Foundation generally,
and is now using Access Handles. Another partner has started a
set test on their project, which would include feedback on the
difference between the APIs from the perspective of new use
cases.

Also, could you summarize the feedback from partners so
far on this origin trial?


Feedback from partners has been very positive: Photoshop Web
reported that both APIs critically unblocked their site, and
did not see significant impact after transitioning to Access
Handles. They use the API as a general purpose storage backend
that can be performantily/easily accessed from Wasm, as well
as a way to manage memory consumption during image editing.
The other partner is also relying on Storage Foundation for
critical bits of their project, although we've gotten less
detailed feedback so far.

On Thu, Jan 20, 2022 at 6:44 PM Chris Harrelson
 wrote:

Hi Emanuel,

A question inline below.

On Thu, Jan 20, 2022 at 7:02 AM Emanuel Krivoy
 wrote:

Hello blink-dev,

We’d like to ask for an extension to our Origin Trial,
from M99 to M101. As mentioned in our previous I2E

,
our partner intended to run a final series of tests
that would allow us to measure the impact of the
changes between Storage Foundation and its successor
Access Handles. The tests were postponed but should
happen in the near future, therefore we’d like to
continue having concurrent Access Handle/Storage
Foundation trials.


Is it accurate to say then that there hasn't been
substantial use on sites recently? Or are they using it
generally but just haven't run the set of tests yet?

Also, could you summarize the feedback from partners so
far on this origin trial?

Please find the Chrome Status template below:

Contact emails

fived...@chromium.org, r...@chromium.org


Explainer

https://github.com/WICG/storage-foundation-api-explainer



Specification

N/A


Summary

Storage 

Re: [blink-dev] Re: Intent to Extend Experiment: Origin Private File System extension: AccessHandle

[Mike West]

Hey Emanuel,

With my comments on the storage foundation I2E

in mind, it looks like good, cross-vendor progress is being made on
refining Access Handles' implementation and specification. There's clear
engagement from partners who have begun using the feature in ways that give
us confidence around it's broad shape and performance characteristics, and
it seems reasonable to me to extend the trial out a bit to give folks time
to hammer out the remaining details together.

LGTM to extend the experiment to 101. Ideally, that will allow y'all to
bring the spec into shape, resolve any remaining disagreements about the
API's behavior, and ensure our implementation matches those decisions.

-mike


On Wed, Jan 26, 2022 at 3:47 PM Yoav Weiss  wrote:

> Would you be able to answer the questions Chris asked on the Storage
> Foundation I2E? They seem relevant here as well. Thanks! :)
>
> On Thursday, January 20, 2022 at 4:06:34 PM UTC+1 Emanuel Krivoy wrote:
>
>> We’d like to ask for an extension to our Origin Trial, from M99 to M101.
>> As mentioned in the Storage Foundation I2E
>> ,
>> our partner intended to run a final series of tests with the new surface,
>> giving us a chance for to measure the impact of some of the design
>> decisions (the effect of a mixed sync/async surface and of all filesystem
>> operations being async). The tests were postponed and should happen in the
>> near future, and so we’d like to extend the trial to be able to gather
>> feedback from them.
>>
>> Please find the Chrome Status template below:
>>
>> Contact emails
>>
>> fived...@chromium.org, r...@chromium.org
>>
>> Explainer
>>
>> https://github.com/WICG/file-system-access/blob/main/AccessHandle.md
>>
>> Specification
>>
>> WIP Draft: https://github.com/WICG/file-system-access/pull/344
>>
>> Summary
>>
>> The Origin Private File System (OPFS, part of the File System Access API)
>> is augmented with a new surface that brings very performant access to data.
>> This new surface differs from existing ones by offering in-place and
>> exclusive write access to a file’s content. This change, along with the
>> ability to consistently read unflushed modifications and the availability
>> of a synchronous variant on dedicated workers, significantly improves
>> performance and unblocks new use cases (especially for porting existing
>> IO-heavy applications to WebAssembly).
>>
>> This Intent-to-Experiment is only in reference to the sync variant of the
>> API i.e., the createSyncAccessHandle() method and the SyncAccessHandle
>> object (only exposed in worker contexts):
>>
>> const handle = await file.createSyncAccessHandle();
>>
>> var writtenBytes = handle.write(buffer);
>>
>> var readBytes = handle.read(buffer {at: 1});
>>
>> The sync variant is meant to be consumed by low-level entities like
>> toolchains. We expect application developers to prefer the async API with
>> its streaming interface which will be shipped later.
>>
>> AccessHandles is the new API shape for what was previously called Storage
>> Foundation API (Intent-to-Experiment:
>> http://groups.google.com/a/chromium.org/g/blink-dev/c/Jhirhnq3WbY.
>>
>>
>> Blink component
>>
>> Blink>Storage>FileSystem
>> 
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/664
>>
>> TAG review status
>>
>> Closed, positive feedback.
>>
>> Risks
>> Interoperability and Compatibility
>>
>> The feature has to be compatible with existing ways to access data on
>> OPFS i.e., createWritable() and getFile(). The use of write locks and
>> care for backwards compatibility should mean that the risk here is low. In
>> order to ease compatibility concerns in the future, we've added an optional
>> 'mode' parameter to createAccessHandle()/createSyncAccessHandle(). This
>> allows us to eventually extend AccessHandle functionality to non-OPFS
>> file systems without necessarily taking the OPFS behaviour as default (more
>> details here:
>> https://github.com/WICG/file-system-access/blob/main/AccessHandle.md#exposing-accesshandles-on-all-filesystems
>> ).
>>
>> There is a risk of interoperability between vendors, pending the position
>> on implementing this surface. This design is the result of feedback from
>> Gecko and WebKit, who reviewed previous iterations of this functionality
>> and gave feedback that it should integrate more strongly with OPFS. We
>> directly shared documents outlining alternatives considered
>> ,
>> and later our recommendation
>> 
>> towards this particular API shape.
>>
>>
>>
>> We believe that the new design, when paired with a separate streams-based
>> 

Re: [blink-dev] Intent to Extend Experiment: Storage Foundation API

[Yoav Weiss]

LGTM2 under the same conditions, for one last extension here.



On Fri, Feb 11, 2022 at 11:14 AM Mike West  wrote:

> Hey Emanuel,
>
> API owners discussed this intent this week and the week before, with a
> fair amount of skepticism around the length of the experimentation (April
> 2021 (90) - May 2022 (101)), and the value of continuing this experiment in
> light of what looks like reasonable alignment from our colleagues in WebKit
> and Gecko on the Access Handles proposal which y'all are working through in
> parallel. With that in mind, the best path forward would be to let this
> experiment expire rather than extending it. Unfortunately, it appears that
> some miscommunication led a partner to begin relying on this API in ways
> that make it difficult for us to simply remove support. This puts us in a
> bit of a pickle.
>
> I'd like to ensure that we don't end up in this situation again in 3
> months if we extend this OT to give the partner time to migrate off of
> Storage Foundation. I think we have solid commitments from them that
> they'll be able to shift onto Access Handles in the timeframe we're
> discussing, and I think we can strengthen that encouragement by allowing
> them to extend their OT tokens once, and then disabling new signups for the
> OT to ensure that new partners don't accidentally land on this instead of
> Access Handles. That's a compromise that seems to me to minimize the
> incremental risk of burn-in, while allowing us to remove this API from the
> platform without user-visible breakage. But it's an unusual extension, so I
> don't think a single LGTM is sufficient to approve it.
>
> LGTM1 to extend the trial to 101 _and_ disable new signups or renewals.
> Ideally, the partner can complete their migration before 101, in which case
> we can end the trial earlier. I'd appreciate other API owners weighing in.
>
> -mike
>
>
> On Tue, Feb 1, 2022 at 4:55 PM Emanuel Krivoy 
> wrote:
>
>> Hi Chris,
>>
>> Replies inline as well:
>>
>> Is it accurate to say then that there hasn't been substantial use on
>>> sites recently? Or are they using it generally but just haven't run the set
>>> of tests yet?
>>>
>>
>> The latter, Photoshop Web used Storage Foundation generally, and is now
>> using Access Handles. Another partner has started a set test on their
>> project, which would include feedback on the difference between the APIs
>> from the perspective of new use cases.
>>
>> Also, could you summarize the feedback from partners so far on this
>>> origin trial?
>>>
>>
>> Feedback from partners has been very positive: Photoshop Web reported
>> that both APIs critically unblocked their site, and did not see significant
>> impact after transitioning to Access Handles. They use the API as a general
>> purpose storage backend that can be performantily/easily accessed from
>> Wasm, as well as a way to manage memory consumption during image editing.
>> The other partner is also relying on Storage Foundation for critical bits
>> of their project, although we've gotten less detailed feedback so far.
>>
>> On Thu, Jan 20, 2022 at 6:44 PM Chris Harrelson 
>> wrote:
>>
>>> Hi Emanuel,
>>>
>>> A question inline below.
>>>
>>> On Thu, Jan 20, 2022 at 7:02 AM Emanuel Krivoy 
>>> wrote:
>>>
 Hello blink-dev,



 We’d like to ask for an extension to our Origin Trial, from M99 to
 M101. As mentioned in our previous I2E
 ,
 our partner intended to run a final series of tests that would allow us to
 measure the impact of the changes between Storage Foundation and its
 successor Access Handles. The tests were postponed but should happen in the
 near future, therefore we’d like to continue having concurrent Access
 Handle/Storage Foundation trials.

>>>
>>> Is it accurate to say then that there hasn't been substantial use on
>>> sites recently? Or are they using it generally but just haven't run the set
>>> of tests yet?
>>>
>>> Also, could you summarize the feedback from partners so far on this
>>> origin trial?
>>>
>>>


 Please find the Chrome Status template below:



 Contact emails

 fived...@chromium.org, r...@chromium.org

 Explainer

 https://github.com/WICG/storage-foundation-api-explainer

 Specification

 N/A

 Summary

 Storage Foundation API is a storage API that resembles a very basic
 filesystem, with direct access to stored data through buffers and offsets.
 Our goal is to give developers flexibility by providing generic, simple,
 and performant primitives upon which they can build higher-level
 components. It's particularly well suited for Wasm-based libraries and
 applications that want to use custom storage algorithms to fine-tune
 execution speed and memory usage.


 Blink component

 Blink>Storage
 

Re: [blink-dev] Intent to Extend Experiment: Storage Foundation API

[Mike West]

Hey Emanuel,

API owners discussed this intent this week and the week before, with a fair
amount of skepticism around the length of the experimentation (April 2021
(90) - May 2022 (101)), and the value of continuing this experiment in
light of what looks like reasonable alignment from our colleagues in WebKit
and Gecko on the Access Handles proposal which y'all are working through in
parallel. With that in mind, the best path forward would be to let this
experiment expire rather than extending it. Unfortunately, it appears that
some miscommunication led a partner to begin relying on this API in ways
that make it difficult for us to simply remove support. This puts us in a
bit of a pickle.

I'd like to ensure that we don't end up in this situation again in 3 months
if we extend this OT to give the partner time to migrate off of Storage
Foundation. I think we have solid commitments from them that they'll be
able to shift onto Access Handles in the timeframe we're discussing, and I
think we can strengthen that encouragement by allowing them to extend their
OT tokens once, and then disabling new signups for the OT to ensure that
new partners don't accidentally land on this instead of Access Handles.
That's a compromise that seems to me to minimize the incremental risk of
burn-in, while allowing us to remove this API from the platform without
user-visible breakage. But it's an unusual extension, so I don't think a
single LGTM is sufficient to approve it.

LGTM1 to extend the trial to 101 _and_ disable new signups or renewals.
Ideally, the partner can complete their migration before 101, in which case
we can end the trial earlier. I'd appreciate other API owners weighing in.

-mike


On Tue, Feb 1, 2022 at 4:55 PM Emanuel Krivoy  wrote:

> Hi Chris,
>
> Replies inline as well:
>
> Is it accurate to say then that there hasn't been substantial use on sites
>> recently? Or are they using it generally but just haven't run the set of
>> tests yet?
>>
>
> The latter, Photoshop Web used Storage Foundation generally, and is now
> using Access Handles. Another partner has started a set test on their
> project, which would include feedback on the difference between the APIs
> from the perspective of new use cases.
>
> Also, could you summarize the feedback from partners so far on this origin
>> trial?
>>
>
> Feedback from partners has been very positive: Photoshop Web reported that
> both APIs critically unblocked their site, and did not see significant
> impact after transitioning to Access Handles. They use the API as a general
> purpose storage backend that can be performantily/easily accessed from
> Wasm, as well as a way to manage memory consumption during image editing.
> The other partner is also relying on Storage Foundation for critical bits
> of their project, although we've gotten less detailed feedback so far.
>
> On Thu, Jan 20, 2022 at 6:44 PM Chris Harrelson 
> wrote:
>
>> Hi Emanuel,
>>
>> A question inline below.
>>
>> On Thu, Jan 20, 2022 at 7:02 AM Emanuel Krivoy 
>> wrote:
>>
>>> Hello blink-dev,
>>>
>>>
>>>
>>> We’d like to ask for an extension to our Origin Trial, from M99 to M101.
>>> As mentioned in our previous I2E
>>> ,
>>> our partner intended to run a final series of tests that would allow us to
>>> measure the impact of the changes between Storage Foundation and its
>>> successor Access Handles. The tests were postponed but should happen in the
>>> near future, therefore we’d like to continue having concurrent Access
>>> Handle/Storage Foundation trials.
>>>
>>
>> Is it accurate to say then that there hasn't been substantial use on
>> sites recently? Or are they using it generally but just haven't run the set
>> of tests yet?
>>
>> Also, could you summarize the feedback from partners so far on this
>> origin trial?
>>
>>
>>>
>>>
>>> Please find the Chrome Status template below:
>>>
>>>
>>>
>>> Contact emails
>>>
>>> fived...@chromium.org, r...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/WICG/storage-foundation-api-explainer
>>>
>>> Specification
>>>
>>> N/A
>>>
>>> Summary
>>>
>>> Storage Foundation API is a storage API that resembles a very basic
>>> filesystem, with direct access to stored data through buffers and offsets.
>>> Our goal is to give developers flexibility by providing generic, simple,
>>> and performant primitives upon which they can build higher-level
>>> components. It's particularly well suited for Wasm-based libraries and
>>> applications that want to use custom storage algorithms to fine-tune
>>> execution speed and memory usage.
>>>
>>>
>>> Blink component
>>>
>>> Blink>Storage
>>> 
>>>
>>> Search tags
>>>
>>> storage , nativeio
>>> , performance
>>> ,