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 <[email protected]> wrote: > > > On Fri, Feb 11, 2022 at 11:53 AM Olli Pettay <[email protected]> > 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 > <https://github.com/WICG/nav-speculation/issues>.) > > Hope this helps! > > >> >> -Olli >> >> On Fri, Feb 11, 2022 at 7:20 AM Kouhei Ueno <[email protected]> wrote: >> >>> Contact emails >>> >>> [email protected], [email protected] >>> >>> 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 >>> <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/ 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/ >>> >>> 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>; >>> 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 >>> >> As the requests are rather recent, it may be interesting to give them some time to respond. >>> 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 >>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>? >>> 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 >>> <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 >>> >>> (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 >>> >>> -- >>> 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/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 >> >> -- >> 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/CAA%2B07GXTt370Y9GVCMn160%2BbuxM_9MizBjbhjMrOsUXQixjcSQ%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA%2B07GXTt370Y9GVCMn160%2BbuxM_9MizBjbhjMrOsUXQixjcSQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9wncTSBUmyAmF7L3fpB2HAzxTLSp-O6Dh04NKLpsE0Ag%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9wncTSBUmyAmF7L3fpB2HAzxTLSp-O6Dh04NKLpsE0Ag%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXKNkOGJYZ7mW33_CNPX5MaXYwDxwVVGUu1Kd9-GtmpkA%40mail.gmail.com.
