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

['Angel Raposo' via blink-dev]

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.

On Tuesday, March 22, 2022 at 11:40:39 PM UTC+9 Joe Medley wrote:

> When are you planning to ship?
> Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 
> 816-678-7195 <(816)%20678-7195>
> *If an API's not documented it doesn't exist.*
>
>
> On Mon, Mar 21, 2022 at 6:18 AM Yoav Weiss  wrote:
>
>> LGTM3
>>
>> On Mon, Mar 21, 2022 at 2:16 PM Mike Taylor  wrote:
>>
>>> LGTM2
>>>
>>> On 3/21/22 8:12 AM, Mike West wrote:
>>>
>>> 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
>>>
>>>
>>> On Wed, Mar 16, 2022 at 5:06 PM Noam Rosenthal  
>>> wrote:
>>>
 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.

 On Wednesday, March 16, 2022 at 5:42:15 PM UTC+2 sligh...@chromium.org 
 wrote:

> 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
>
> On Tuesday, March 15, 2022 at 7:10:12 AM UTC-7 Kouhei Ueno wrote:
>
>> 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?
>>>

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

['Joe Medley' via blink-dev]

When are you planning to ship?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Mar 21, 2022 at 6:18 AM Yoav Weiss  wrote:

> LGTM3
>
> On Mon, Mar 21, 2022 at 2:16 PM Mike Taylor 
> wrote:
>
>> LGTM2
>>
>> On 3/21/22 8:12 AM, Mike West wrote:
>>
>> 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
>>
>>
>> On Wed, Mar 16, 2022 at 5:06 PM Noam Rosenthal <
>> noam.j.rosent...@gmail.com> wrote:
>>
>>> 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.
>>>
>>> On Wednesday, March 16, 2022 at 5:42:15 PM UTC+2 sligh...@chromium.org
>>> wrote:
>>>
 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

 On Tuesday, March 15, 2022 at 7:10:12 AM UTC-7 Kouhei Ueno wrote:

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

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

[Yoav Weiss]

LGTM3

On Mon, Mar 21, 2022 at 2:16 PM Mike Taylor  wrote:

> LGTM2
>
> On 3/21/22 8:12 AM, Mike West wrote:
>
> 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
>
>
> On Wed, Mar 16, 2022 at 5:06 PM Noam Rosenthal 
> wrote:
>
>> 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.
>>
>> On Wednesday, March 16, 2022 at 5:42:15 PM UTC+2 sligh...@chromium.org
>> wrote:
>>
>>> 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
>>>
>>> On Tuesday, March 15, 2022 at 7:10:12 AM UTC-7 Kouhei Ueno wrote:
>>>
 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 g

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

[Mike Taylor]

LGTM2

On 3/21/22 8:12 AM, Mike West wrote:

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


On Wed, Mar 16, 2022 at 5:06 PM Noam Rosenthal 
 wrote:


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.

On Wednesday, March 16, 2022 at 5:42:15 PM UTC+2
sligh...@chromium.org wrote:

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

On Tuesday, March 15, 2022 at 7:10:12 AM UTC-7 Kouhei Ueno wrote:

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

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

[Mike West]

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


On Wed, Mar 16, 2022 at 5:06 PM Noam Rosenthal 
wrote:

> 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.
>
> On Wednesday, March 16, 2022 at 5:42:15 PM UTC+2 sligh...@chromium.org
> wrote:
>
>> 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
>>
>> On Tuesday, March 15, 2022 at 7:10:12 AM UTC-7 Kouhei Ueno wrote:
>>
>>> 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.
>

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

[Noam Rosenthal]

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.

On Wednesday, March 16, 2022 at 5:42:15 PM UTC+2 sligh...@chromium.org 
wrote:

> 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
>
> On Tuesday, March 15, 2022 at 7:10:12 AM UTC-7 Kouhei Ueno wrote:
>
>> 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. 

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

[Alex Russell]

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

On Tuesday, March 15, 2022 at 7:10:12 AM UTC-7 Kouhei Ueno wrote:

> 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  wrote:
>
>>
>> El dom., 20 de febrero de 2022 3:34 a. m., Noam Rosenthal <
>> noam.j.rosent...@gmail.com> escribió:
>>
>
>>>
>>> On Sun, Feb 20, 2022 at 12:10 PM Jacob G  wrote:
>>>
 Maybe a weird side-effect, but think of we

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

['Kouhei Ueno' via 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  wrote:

>
> El dom., 20 de febrero de 2022 3:34 a. m., Noam Rosenthal <
> noam.j.rosent...@gmail.com> escribió:
>
>>
>>
>> On Sun, Feb 20, 2022 at 12:10 PM Jacob G  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.
>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receivi

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

[Jacob G]

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)

noam.j.r...@gmail.com schrieb am Mittwoch, 16. Februar 2022 um 17:51:00 
UTC+1:

> 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!
> https://github.com/WICG/nav-speculation/issues/138
>  
>
>>

-- 
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/7ec8c1d3-e443-441b-882e-73e0511de8f3n%40chromium.org.

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

[Noam Rosenthal]

On Sun, Feb 20, 2022 at 12:10 PM Jacob G  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.

>

-- 
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/CAGttnEWV-HxsXds4W-ZcH_Aro4uvG1%2BjLmkM9io6xApi8LpjGA%40mail.gmail.com.

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

[Noam Rosenthal]

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!
https://github.com/WICG/nav-speculation/issues/138
 

>

-- 
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/e2a15552-82a1-434e-af85-a1c61ae07554n%40chromium.org.

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

[Alex Russell]

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

On Wednesday, February 16, 2022 at 12:44:53 AM UTC-8 noam.j.r...@gmail.com 
wrote:

> I created an issue specifically for the BroadcastChannel discussion:
> https://github.com/WICG/nav-speculation/issues/141
>
> We'd love to hear if there are other issues with restrictions (or other) 
> that need addressing!
> Browse/open at https://github.com/WICG/nav-speculation/issues
>
> On Monday, February 14, 2022 at 6:38:40 PM UTC+2 dom...@chromium.org 
> wrote:
>
>> On Mon, Feb 14, 2022 at 11:33 AM Noam Rosenthal  
>> wrote:
>>
>>>
>>>
>>> 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  
 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.

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

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.

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

[Noam Rosenthal]

I created an issue specifically for the BroadcastChannel discussion:
https://github.com/WICG/nav-speculation/issues/141

We'd love to hear if there are other issues with restrictions (or other) 
that need addressing!
Browse/open at https://github.com/WICG/nav-speculation/issues

On Monday, February 14, 2022 at 6:38:40 PM UTC+2 dom...@chromium.org wrote:

> On Mon, Feb 14, 2022 at 11:33 AM Noam Rosenthal  
> wrote:
>
>>
>>
>> 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  
>>> 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.
>>>

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

-- 
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/15f1995e-e8e8-4851-9607-69116672dfe5n%40chromium.org.

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

[Domenic Denicola]

On Mon, Feb 14, 2022 at 11:33 AM Noam Rosenthal 
wrote:

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

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.

-- 
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/CAM0wra_sYWF2iuoX9UAofpQQxaxNmO2J1Ui8zCsZi4v0mQ9fEg%40mail.gmail.com.

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

[Noam Rosenthal]

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

-- 
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/726d402c-8154-4118-8a59-28da00e55541n%40chromium.org.

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 N

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

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

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 

[blink-dev] Intent to Ship: Omnibox Prerendering

[Kouhei Ueno]

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