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 <[email protected]> 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 [email protected] > 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 >>> <https://github.com/WICG/nav-speculation/blob/main/ua-initiated-prerendering.md#opting-out> >>> 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 >>> <https://github.com/WICG/nav-speculation/issues/141>, implementation >>> <https://chromium-review.googlesource.com/c/chromium/src/+/3517385>]. >>> In addition, we are delaying ServiceWorker#postMessage too, to address a >>> similar issue [crbug <https://crbug.com/1305120>] >>> >>> Q: Can Enterprise disable the feature by a policy? >>> >>> A: Yes - we respect the existing NetworkPredictionOptions >>> <https://chromeenterprise.google/policies/#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 >>> <https://github.com/WICG/nav-speculation/issues>. >>> >>> 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 >>> <https://forums.macrumors.com/threads/safari-trying-to-pre-load-urls.1736761/>, >>> Opera from 2017 >>> <https://www.ghacks.net/2017/02/07/opera-43-better-performance-classic-link-selection/#:~:text=cursor%20vertically%20instead.-,Instant%20Page%20Loading,-Instant%20Page%20Loading>, >>> 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 <[email protected]> wrote: >>> >>>> >>>> El dom., 20 de febrero de 2022 3:34 a. m., Noam Rosenthal < >>>> [email protected]> escribió: >>>> >>> >>>>> >>>>> On Sun, Feb 20, 2022 at 12:10 PM Jacob G <[email protected]> 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 [email protected]. >>>>> >>>> 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 >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGttnEWV-HxsXds4W-ZcH_Aro4uvG1%2BjLmkM9io6xApi8LpjGA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> >>> >>> -- >>> kouhei >>> >> -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7bb9cb46-420e-4111-9be5-93eae359f606n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7bb9cb46-420e-4111-9be5-93eae359f606n%40chromium.org?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3Dd1fiaO0ner0xAKNub%2BaZYr00OWRXACHM3xygyVMKAKLw%40mail.gmail.com.
