Intent to Ship: Omnibox Prerendering

609 views
Skip to first unread message

Kouhei Ueno

unread,
Feb 11, 2022, 12:20:40 AMFeb 11
to blink-dev

Contact emails

loadi...@chromium.org, noam.j.r...@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 prerendering, we minimize this by having a high confidence threshold value: We only issue prerendering for omnibox input that we are confident that the user will navigate to the page.


Interoperability

Gecko: Some informal positive discussion with Gecko engineers on the HTML Standard issue tracker and in the HTML triage call; formal positions request here: https://github.com/mozilla/standards-positions/issues/613


WebKit: WebKit already ships URL-bar triggered prerendering, but not any APIs for letting pages know about it, and it's unclear what strategy they are using to prohibit disruptive behaviors for prerendered pages. We have reached out for a formal positions request here in the hopes of moving toward interoperability: https://lists.webkit.org/pipermail/webkit-dev/2022-February/032113.html


Web / Framework developers: N/A - The omnibox prerendering (scope of this I2S) is triggered without web author opt-in. See https://github.com/WICG/proposals/issues/2 for positive sentiments on speculationrules triggered prerendering.


Ergonomics

These features will be used by speculation rules-triggered prerender as well.


Activation

Developer activation is not needed. Omnibox prerendering is triggered by Chrome.


Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
It is not currently possible to trigger the omnibox prerendering path specifically from web platform tests. We have filed web-platform-tests/wpt#32726 to discuss making it possible and will be working on driving that forward in collaboration with other browsers.

In the meantime, we have written a lot of web platform tests using speculation rules as the trigger. These exercise many of the same code paths and can be adapted once an appropriate API is available for testing URL-bar-triggered prerendering:


https://wpt.fyi/results/speculation-rules/prerender?label=experimental&label=master&aligned

(Currently Chromium tests this using VirtualTestSuites [cs] instead of EnableExperimentalWebPlatformFeatures, so the tests are not green on wpt.fyi.)


Entry on the feature dashboard

https://chromestatus.com/feature/5710069172797440

Olli Pettay

unread,
Feb 11, 2022, 11:53:11 AMFeb 11
to Kouhei Ueno, blink-dev
On 2/11/22 07:20, Kouhei Ueno wrote:
> Contact emails
>
> loadi...@chromium.org <mailto:loadi...@chromium.org>, noam.j.r...@gmail.com <mailto:noam.j.r...@gmail.com>
> <https://github.com/whatwg/html/issues/7533>
>
>
> The corresponding TAG review is w3ctag/design-reviews#667 <https://github.com/w3ctag/design-reviews/issues/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
> <https://developers.google.com/web/updates/2018/07/nostate-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
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/tcbtZoQIlvI/m/K26gVfbUAQAJ>) 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 <https://docs.google.com/document/d/1GenZDPbTzRyp038gh8A_ylIoVTfKt40MFyg7Ek_7L58/edit>.
>
>
> 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
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/tcbtZoQIlvI/m/K26gVfbUAQAJ>).
>
>
> 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/
> <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
> <https://docs.google.com/document/d/1sUbxYSu1o5G76tA4UW_xxgcfcOn8j6NlJc_Go0Gwb_Q/edit?usp=sharing>
>
> Demo page: https://omnibox-prerender.glitch.me/ <https://omnibox-prerender.glitch.me/>
>
>
> Debuggability
>
> We are actively talking to the devtools team about adding general Prerender support to it [metabug
> <https://bugs.chromium.org/p/chromium/issues/detail?id=1217029>]. 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
> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/public/mojom/web_feature/web_feature.mojom;l=3482>] 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
> <https://blog.chromium.org/2011/06/prerendering-in-chrome.html>. A similar behavior is also present in other browsers (e.g. “Preload Top Hit” feature
> in Safari).
>
> For omnibox prerendering, we minimize this by having a high confidence threshold value: We only issue prerendering for omnibox input that we are
> confident that the user will navigate to the page.
>
>
> Interoperability
>
> Gecko: Some informal positive discussion with Gecko engineers on the HTML Standard issue tracker
> <https://github.com/whatwg/html/issues/7533#issuecomment-1022051187>and in the HTML triage call
> <https://github.com/whatwg/html/issues/7488#issuecomment-1029510684>;


FWIW, that positive signal was to have a spec for this. The spec proposal has not been reviewed and obviously the spec is still missing quite a bit.
It is a bit surprising to ship anything when there is no clear spec how it all should behave.
(It is for example quite surprising that one could use BroadcastChannel with a prerendered page. And [DelayWhilePrerendering] also has very surprising
behavior)


-Olli

formal positions request here:
> https://github.com/mozilla/standards-positions/issues/613 <https://github.com/mozilla/standards-positions/issues/613>
>
>
> WebKit: WebKit already ships URL-bar triggered prerendering, but not any APIs for letting pages know about it, and it's unclear what strategy they are
> using to prohibit disruptive behaviors for prerendered pages. We have reached out for a formal positions request here in the hopes of moving toward
> interoperability: https://lists.webkit.org/pipermail/webkit-dev/2022-February/032113.html
> <https://lists.webkit.org/pipermail/webkit-dev/2022-February/032113.html>
>
>
> Web / Framework developers:N/A - The omnibox prerendering (scope of this I2S) is triggered without web author opt-in. See
> https://github.com/WICG/proposals/issues/2 <https://github.com/WICG/proposals/issues/2>for positive sentiments on speculationrules triggered prerendering.
>
>
> Ergonomics
>
> These features will be used by speculation rules-triggered prerender as well.
>
>
> Activation
>
> Developer activation is not needed. Omnibox prerendering is triggered by Chrome.
>
>
> Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>? Link
> to test suite results from wpt.fyi <https://wpt.fyi>.
> It is not currently possible to trigger the omnibox prerendering path specifically from web platform tests. We have filed web-platform-tests/wpt#32726
> <https://github.com/web-platform-tests/wpt/issues/32726>to discuss making it possible and will be working on driving that forward in collaboration
> with other browsers.
>
> In the meantime, we have written a lot of web platform tests using speculation rules as the trigger. These exercise many of the same code paths and
> can be adapted once an appropriate API is available for testing URL-bar-triggered prerendering:
>
>
> https://wpt.fyi/results/speculation-rules/prerender?label=experimental&label=master&aligned
> <https://wpt.fyi/results/speculation-rules/prerender?label=experimental&label=master&aligned>
>
> (Currently Chromium tests this using VirtualTestSuites [cs
> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/virtual/prerender/README.md>] instead of
> EnableExperimentalWebPlatformFeatures, so the tests are not green on wpt.fyi.)
>
>
> Entry on the feature dashboard <http://www.chromestatus.com/>
>
> https://chromestatus.com/feature/5710069172797440 <https://chromestatus.com/feature/5710069172797440>
>
> --
> 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+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPVAxLVDPme9kEnB6NdeDHO6krO77D-GN8MMKzYAv8oLCyAtwA%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPVAxLVDPme9kEnB6NdeDHO6krO77D-GN8MMKzYAv8oLCyAtwA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

Olli Pettay

unread,
Feb 11, 2022, 11:53:12 AMFeb 11
to Kouhei Ueno, blink-dev
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

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPVAxLVDPme9kEnB6NdeDHO6krO77D-GN8MMKzYAv8oLCyAtwA%40mail.gmail.com.


--
-Olli

Domenic Denicola

unread,
Feb 11, 2022, 5:39:45 PMFeb 11
to Olli Pettay, Kouhei Ueno, blink-dev
On Fri, Feb 11, 2022 at 11:53 AM Olli Pettay <olli....@gmail.com> 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!
 

Yoav Weiss

unread,
Feb 12, 2022, 12:11:29 AMFeb 12
to Domenic Denicola, Olli Pettay, Kouhei Ueno, blink-dev
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 <dom...@chromium.org> wrote:


On Fri, Feb 11, 2022 at 11:53 AM Olli Pettay <olli....@gmail.com> 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.
As the requests are rather recent, it may be interesting to give them some time to respond. 

Noam Rosenthal

unread,
Feb 14, 2022, 11:33:18 AMFeb 14
to blink-dev, yoav...@chromium.org, Smaug, Kouhei Ueno, blink-dev, dom...@chromium.org
On Saturday, February 12, 2022 at 7:11:29 AM UTC+2 yoav...@chromium.org wrote:
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 <dom...@chromium.org> wrote:


On Fri, Feb 11, 2022 at 11:53 AM Olli Pettay <olli....@gmail.com> 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.

Re. BroadcastChannel and friends - it's a totally valid point and there's an open issue about it (https://github.com/WICG/nav-speculation/issues/113). I feel that we should examine these especially as we move from omnibox to document-initiated prerenering.

Domenic Denicola

unread,
Feb 14, 2022, 11:38:40 AMFeb 14
to Noam Rosenthal, blink-dev, yoav...@chromium.org, Smaug, Kouhei Ueno, dom...@chromium.org
Yeah, just to be clear, I agree page-initiated prerendering multiplies the risks significantly and will thus need more work.  I expect there will still be some implementation-dependent behavior (e.g., some implementations may discard a prerender if they use a disruptive API, while others might delay the API results). But things like "does BroadcastChannel work at all or not" are critical to nail down for interoperable page-initiated prerendering.
 

Noam Rosenthal

unread,
Feb 16, 2022, 3:44:53 AMFeb 16
to blink-dev, dom...@chromium.org, blink-dev, yoav...@chromium.org, Smaug, Kouhei Ueno, Noam Rosenthal
I created an issue specifically for the BroadcastChannel discussion:

We'd love to hear if there are other issues with restrictions (or other) that need addressing!

Alex Russell

unread,
Feb 16, 2022, 11:48:00 AMFeb 16
to blink-dev, noam.j.r...@gmail.com, Domenic Denicola, blink-dev, Yoav Weiss, Smaug, Kouhei Ueno
hey folks,

Looking at this in API OWNERS this morning, I wasn't able to see an obvious developer opt-out. The spec and explainer talk about letting the server opt-out, but it appears that the primary way that would happen is aborting a response. This is a potentially expensive and surprising for servers. Has there been any thought about supporting a response header that would allow a response document to opt into, e.g., only prefetch behavior but not prerendering?

Best Regards,

Alex

Noam Rosenthal

unread,
Feb 16, 2022, 11:51:00 AMFeb 16
to blink-dev, sligh...@chromium.org, Noam Rosenthal, dom...@chromium.org, blink-dev, yoav...@chromium.org, Smaug, Kouhei Ueno
On Wednesday, February 16, 2022 at 6:48:00 PM UTC+2 sligh...@chromium.org wrote:
hey folks,

Looking at this in API OWNERS this morning, I wasn't able to see an obvious developer opt-out. The spec and explainer talk about letting the server opt-out, but it appears that the primary way that would happen is aborting a response. This is a potentially expensive and surprising for servers. Has there been any thought about supporting a response header that would allow a response document to opt into, e.g., only prefetch behavior but not prerendering?

correct, it's still in discussion, and feedback is very welcome!
 

Noam Rosenthal

unread,
Feb 20, 2022, 6:34:58 AMFeb 20
to Jacob G, blink-dev, sligh...@chromium.org, dom...@chromium.org, yoav...@chromium.org, Smaug, Kouhei Ueno


On Sun, Feb 20, 2022 at 12:10 PM Jacob G <kurte...@gmail.com> wrote:
Maybe a weird side-effect, but think of web.whatsapp.com: You have the tab open already, open a new tab, enter web.whatsapp.com, so you'll get an action item in the omnibox to switch to the already open tab - but with prerendering this leads to web.whatsapp.com showing you've opened the site in a new tab (even though you didn't - it got prerendered), making the "switch to already open tab" suggestion useless.
Is this something site maintainers will have to fix or on the chromium side? (Prerendering interaction with already open tabs)
This is exactly the open issue discussed here: https://github.com/WICG/nav-speculation/issues/141
We want the default behavior to not create unexpected behavior such as the ones you've described.

Jacob G

unread,
Feb 22, 2022, 12:00:21 AMFeb 22
to blink-dev, noam.j.r...@gmail.com, sligh...@chromium.org, dom...@chromium.org, blink-dev, yoav...@chromium.org, Smaug, Kouhei Ueno
Maybe a weird side-effect, but think of web.whatsapp.com: You have the tab open already, open a new tab, enter web.whatsapp.com, so you'll get an action item in the omnibox to switch to the already open tab - but with prerendering this leads to web.whatsapp.com showing you've opened the site in a new tab (even though you didn't - it got prerendered), making the "switch to already open tab" suggestion useless.
Is this something site maintainers will have to fix or on the chromium side? (Prerendering interaction with already open tabs)

Kouhei Ueno

unread,
Mar 15, 2022, 10:10:12 AMMar 15
to blink-dev

Hi,


While we are discussing, we would like to continue the incremental roll out of the feature to non-Stable channels. As of now, we are testing out the feature on 60% of Dev/Canary channels, and 60% of Beta channels. The rollout is limited to Android Chrome (limitation of the current implementation).


We expect the rollout to affect at most a tiny fraction of the Internet traffic generated by Chrome. The population of the Beta/Dev/Canary channels combined is less than a few percent of Stable population, and the navigation subject to prerendering on Prerendering-enabled Chrome is less than a percent.


Let me try to summarize the state of the discussion here (including the questions we’ve received out-of-band).


Q: Do you offer an opt-out mechanism to developers?

A: Yes. The opt-out mechanism is now covered in this section of the explainer.


Q: What can we do about prerender breaking “switch to already open tab” on WhatsApp?

A: We are updating the BroadcastChannel interaction [spec, implementation]. In addition, we are delaying ServiceWorker#postMessage too, to address a similar issue [crbug]


Q: Can Enterprise disable the feature by a policy?

A: Yes - we respect the existing NetworkPredictionOptions group policy.


Q: What is the status of https://github.com/whatwg/html/issues/7533?

A: The issue is a general “call for feedback” issue. Individual issues are tracked on wicg/nav-speculation issue tracker.


Q: Since prerendering risks breaking certain websites, what are the mitigation measures planned?

A:

Prerendering is not entirely new. It used to be available in Chrome M13 until M63 and has been available in many other browsers such as: Safari since at least 2014, Opera from 2017, and more recently launched in Edge. We assume that the risk of breakage is relatively low given these pre-existing conditions. That said, we will remain prudent while relaunching this feature.


  1. Take a slow and transparent approach to our rollout:

    1. We’ll be careful around ramping up the experiment group population that we will be monitoring the metrics and user reports closely.

    2. We’ll also be transparent about the rollout config on this blink-dev thread.

    3. We’ll be keeping in touch with various partners to ensure that everything is good on their end.

  2. Before going to Stable, we’ll publish a heads-up article on one of our blogs with the following content:

    1. What’s being experimented with (e.g. prerendering on Chrome for Android from the Omnibox)

    2. Things to know about this feature (e.g. how it triggers, how it manifests itself, how it works)

    3. How to do hands-on testing, what to do if something breaks (e.g. opt-out), how to share feedback to help us get this right.

  3. Being as conservative as other prerendering browsers (such as Edge and Safari), as well as having the following extra mitigations:

    1. Allowing developers to opt-outs.

    2. Disabling prerendering on features known to be problematic or surprising (e.g. BroadcastChannel, Media, and Sensor APIs)


--

Kouhei, on behalf of the Prerender2 team



On Mon, Feb 21, 2022 at 1:48 AM Coco Trana <cocot...@gmail.com> wrote:

--
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+...@chromium.org.


--
kouhei

Alex Russell

unread,
Mar 16, 2022, 11:42:15 AMMar 16
to blink-dev, Kouhei Ueno
Hey Kouhei,

Thanks for highlighting that there's an opt-out option now. I'm a little concerned that it requires servers to avoid sending a response at all, forcing an early decision by the infrastructure rather than allowing pages requested this way to be prefetched by not prerendered (by, e.g., sending a response header that says "prefetch is fine, but please don't render me").

Are there plans for such a header? It would go a long way to making me comfortable with this feature.

Regards

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Noam Rosenthal

unread,
Mar 16, 2022, 12:06:40 PMMar 16
to blink-dev, sligh...@chromium.org, Kouhei Ueno
Yes, there are plans for such a header, join the discussion here: https://github.com/WICG/nav-speculation/issues/138
However so far fleshing out its details was not deemed a blocker for releasing prerender - a simple "all or nothing" opt-out seemed sufficient as a first step.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Mike West

unread,
Mar 21, 2022, 8:12:50 AMMar 21
to Noam Rosenthal, Kouhei Ueno, blink-dev, sligh...@chromium.org
LGTM1.

The two issues I considered blocking were Alex's concerns around opt-out, and the BroadcastChannel integration. It seems to me like there's still discussion to be had on even better solutions than y'all have landed on for both (headers in the one case, more explicit integration with BroadcastChannel in the other), but if there's agreement on the current set of approaches, then your current rollout plan looks reasonable.

Thanks!

-mike


Mike Taylor

unread,
Mar 21, 2022, 9:16:08 AMMar 21
to Mike West, Noam Rosenthal, Kouhei Ueno, blink-dev, sligh...@chromium.org

Yoav Weiss

unread,
Mar 21, 2022, 9:17:49 AMMar 21
to Mike Taylor, Mike West, Noam Rosenthal, Kouhei Ueno, blink-dev, sligh...@chromium.org

Joe Medley

unread,
Mar 22, 2022, 10:40:39 AMMar 22
to Yoav Weiss, Mike Taylor, Mike West, Noam Rosenthal, Kouhei Ueno, blink-dev, sligh...@chromium.org
When are you planning to ship?
Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.


Angel Raposo

unread,
Apr 26, 2022, 12:06:38 PMApr 26
to blink-dev, Joe Medley, mike...@chromium.org, mk...@chromium.org, noam.j.r...@gmail.com, Kouhei Ueno, blink-dev, sligh...@chromium.org, yoav...@chromium.org

Hi,

Following the previous discussion on this thread, I wanted to share a couple of updates:

  • We have updated the web.dev article with the current state and some useful information for web developers as requested. This includes Omnibox prerendering and the new HTTP header `Sec-Purpose: prefetch; prerender`

  • We are also ramping up the experiment gradually, at a very low rate, so we can monitor the situation and we haven’t detected any issues so far. We’ll keep a close eye as we ramp up the roll out


Thanks,

Angel.

Reply all
Reply to author
Forward
0 new messages