PSA: WebNavigation API and Back/Forward Cache

[Dave Tapuska]

The Chrome team is actively experimenting with Back/Forward Cache for desktop and I wanted to call out some behavioral changes that extensions will experience with the WebNavigation API beginning in M92.

The changes match behaviorally what Mozilla has shipped in Firefox with its implementation, so we hope that we are following a well lit path.

Extensions will receive onBeforeNavigate, onCommited and onCompleted events when a page is restored from the Back/Forward cache but not the onDOMContentLoaded event. This is because the DOM content has already been loaded on the page.

The normal event flow is as follows:

First Navigation:

onBeforeNavigate -> onCommitted -> onDOMContentLoaded -> onCompleted

Restoring Navigation from Back/Forward Cache:

onBeforeNavigate -> onCommitted -> onCompleted

When a page is restored from the Back/Forward Cache, an extension may see a previous webNavigation event again. So care must be taken not to apply an operation to a page multiple times. For example, an extension which darkens a page in the onCompleted event should take care to not apply the operation a second time when the page is restored from the Back/Forward Cache. There are a few solutions to this behavior such as using the onDOMContentLoaded event which fires only when the page first loads or storing some state in the content script injected on the page.

If you wish to enable Back/Forward Cache and enable extension support you can launch chrome from the command line with the following flags:

--enable-features=BackForwardCache:content_injection_supported/true/all_extensions_allowed/true/TimeToLiveInBackForwardCacheInSeconds/180 

These instructions will likely change in the future, but we will try to reply to this thread if they do update. To verify something is in the Back/Forward Cache check chrome://process-internals/#web-contents

Experimentation with Back/Forward Cache should begin in M92 releases in various channels. Please reach out via email or crbug.com if you find any issues or have concerns.

dave.

[Cuyler Stuwe]

Is this going to reach the documentation, or is this group the only place where this change will be noted?

In the past, there have been some changes (e.g., requiring “extraHeaders” item in an array) that took effect for a handful of stable Chrome versions before finally being documented. I’m hoping that process has been improved by now. 

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAHgVhZXqeivaHtbCRbqfO3M1dLgFT23SsBhBP_KRVgyp71YTDw%40mail.gmail.com.

[Alexei Miagkov]

Hi Dave, to be clear, what are the changes to the WebNavigation API exactly?

[Dave Tapuska]

The documentation was updated the other week. This is an email calling it out so you are aware. If you are using other documentation that hasn't been updated I'd like to hear about it.

dave.

[Dave Tapuska]

I'm not sure how I can relay the information in another sense, I thought it was clear. For a restored page you will receive onBeforeNavigate, onCommitted, onCompleted but not onDOMContentLoaded.

dave.

[Cuyler Stuwe]

It's good that the docs are being updated ahead of changes now; That was definitely my question.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAHgVhZXw-Jq4MnrGaiNZJsbGLxfY7wrm2grECsFu%2BAQv0Bcp3A%40mail.gmail.com.

[wOxxOm]

Is it technically possible for Chrome to expose bfcache flag in chrome.webNavigation events so that extensions see the navigation was restored from bfcache?

[Dave Tapuska]

While it is technically possible it was clear it was not needed. Firefox does not do this and they have shipped Back/Forward Cache for a long while and we did not see any feature requests requesting this feature in their bug tracker. If you have evidence that it is difficult to accommodate this with any Firefox extensions you've written I would be happy to hear that. There was some initial discussion on whether the transition_qualifier should change but that was quickly ruled out as it would break backwards compatibility. 

dave.