URL-bar triggered prerendering

[domenic]

Today, Safari and Edge ship URL-bar triggered prerendering. Chrome is preparing to do so too. Ideally we'd like to do so in a way that is interoperable, and also clear to developers what is going on.

We've been working on a spec for this at https://wicg.github.io/nav-speculation/prerendering.html . Some of it goes beyond the scope of this issue, e.g. that document has a draft of how we envision <link rel="prerender"> working, and has some (incomplete) considerations for how to handle cross-origin prerendering in a privacy-preserving way, by avoiding storage and credential access. But much of it is applicable to URL-bar triggered prerendering.

In particular, we think it would be valuable to get interop on (and merge into main specs ASAP instead of monkeypatching):

• Prevention of intrusive behaviors, i.e. clear specs on exactly how APIs such as geolocation, media autoplay, or alert() behave while prerendering. For example, we have some reports from early testing that people were able to get Safari to start doing speech synthesis by typing a certain URL in the URL bar, without pressing enter, because they were prerendering a page that used the speech synthesis API and didn't disable it in the prerendering context.

• An API for developers to detect prerendering and react to becoming activated, as well as integration into the performance timeline API. This is useful for, e.g., counting prerenders differently in analytics, or avoiding fetching large video resources. See the explainer for more background.

• The foundational basic concept of a browsing context that is being prerendered, and how navigation works inside those browsing contexts. For example, we want to ensure that if a prerendered page is activated, it doesn't suddenly come with four session history entries; thus we've specified that all navigations while prerendering get converted to replacement navigations.

If other implementers are interested in achieving interop in these areas, we'd love to do the work to merge the relevant parts of the spec into HTML, so that web developers have a clear idea of how URL-bar-triggered prerenders affect their page and the APIs they call. Maybe we can even add an API to WebDriver to trigger URL-bar-based prerendering and thus write web platform tests for all these behaviors.

Ideally, this can also serve as a future starting point for more ambitious work on things like <link rel="prerender"> or other web-page-triggered mechanisms of prerendering. But those are much more complicated and we think the right place to start is user-initiated prerenders, which are still web-observable, but involve only a single party.

Thoughts?

[annevk]

In general this sounds good to me. I wonder what the best way to achieve some of this may be in a way that doesn't lead to new specifications having to build for many types of documents. Can the fully active concept perhaps be reused here?

[domenic]

I wonder what the best way to achieve some of this may be in a way that doesn't lead to new specifications having to build for many types of documents. Can the fully active concept perhaps be reused here?

I don't think it can be used as-is, although maybe it could be split up a bit. In particular, non-fully-active documents have inactive event loops (i.e. with no tasks running), which kind of defeats the point of prerendering.

More generally, for "intrusive" APIs, we have a few broad possibilities for things to do while a page is prerendered or in bfcache:

• Discard: Cause the prerendered/bfcached document to be discarded
• (If async) Delay: Delay the promise/callback until the document becomes active
• Fail: immediately count the process as failed, e.g. return a rejected promise, throw an exception, or silently return a sentinel value (e.g. null from window.open() or false from window.confirm())

It seems like in most bfcache cases we've choosen "fail". Whereas in most prerendering cases we've so far specced "delay", although in the Chromium implementation we plan to start a number of them with "discard" and then move them to "delay" over time to improve coverage.

Part of this difference seems to be based on the does-it-run-JavaScript split. I.e., if you use (say) geolocation from a bfcached page, something pretty weird must have happened, so "fail" seems OK. Whereas if you prerender a page with an embedded map, it could very legitimately request geolocation permissions while prerendering, so "delay" seems much better.

It's probably worth doing some spec footwork though so that for APIs which do want the same result (e.g., window.confirm()) it is easy to get that without too much extra work. And maybe even making the system have a good default, i.e. if you don't specifically account for prerendering, you get fail or delay or something by default?? (Although for bfcache we didn't manage to do that.)

[noamr]

It's probably worth doing some spec footwork though so that for APIs which do want the same result (e.g., window.confirm()) it is easy to get that without too much extra work. And maybe even making the system have a good default, i.e. if you don't specifically account for prerendering, you get fail or delay or something by default?? (Although for bfcache we didn't manage to do that.)

I think it should go with discard by default and we should avoid fail as much as possible. fail means that once the page is activated it's possibly at an error state that could have been avoided if we didn't prerender. That's a potential degradation of user experience...

We should use fail only for cases where anyway the developer can expect failure, e.g. requestFullScreen.