Closed Bug 1734991 Opened 3 years ago Closed 3 years ago

Content scripts don't rerun with BFCache + fission

Categories

(WebExtensions :: General, defect)

Firefox 94
defect

Tracking

(firefox93 affected, firefox94 affected, firefox95 affected)

RESOLVED INVALID
Tracking Status
firefox93 --- affected
firefox94 --- affected
firefox95 --- affected

People

(Reporter: woxxom, Unassigned)

Details

Attachments

(1 file)

830 bytes, application/x-zip-compressed
Details
Attached file test-ff-ext.zip

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.71 Safari/537.36

Steps to reproduce:

  1. go to about:config and enable fission.autostart, restart Firefox if the value was false
  2. install the attached extension
  3. open a new tab, open devtools console
  4. paste-and-go to https://thumbs3.imagebam.com/23874/626770238732222.jpg
  5. Press the back button, then forward button

Actual results:

Devtools console doesn't contain GOOD printed by extension

Expected results:

Devtools console contains GOOD printed by extension

Bisected to https://hg.mozilla.org/integration/autoland/rev/7d326719 that enabled BFCache in FF91.

If the new behavior is intentional, it needs to be documented in https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_scripts and there should be some kind of public announcement for extension developers, probably, before Fission is enabled by default in FF96 (bug 1732358).

Hello,

I reproduced the issue on the latest Nightly (95.0a1/20211010214947), Beta (94.0b4/20211010185747) and Release (93.0/20210927210923) under Windows 10 x64 and Ubuntu 16.04 LTS.

With Fission enabled, performing step 4 will not print “GOOD” to the console. With Fission disabled, the extension will properly print the message to console.

Status: UNCONFIRMED → NEW
Ever confirmed: true

FWIW, Chrome reruns content scripts in this scenario (as tested in Chrome Canary 97) and its devtools Application panel says bfcache was used, however judging by https://crbug.com/1211476 there are cases when the content scripts won't rerun in Chrome.

This is by design, neither page scripts nor extension content scripts are re-run when page is restored from BFCache, there are pageshow and pagehide events that your content script can respond to to continue operating. See this page for more details https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/1.5/Using_Firefox_1.5_caching

(In reply to wOxxOm from comment #3)

FWIW, Chrome reruns content scripts in this scenario (as tested in Chrome Canary 97) and its devtools Application panel says bfcache was used, however judging by https://crbug.com/1211476 there are cases when the content scripts won't rerun in Chrome.

If they do, I suspect that's a bug, as they say explicitly:

Add test that ensures content scripts execute only once.

Add a test that sets state inside the page on each stage. Ensure that the state is correct after restoring the page from the back/forward cache. This ensures that the scripts are not executed on restore (since they have already executed on the initial load).

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID

Personally, I'm aware of this behavior, but what about others - will they find this info page? Would they even read something about an ancient Firefox 1.5?

The problem is that the behavior of content scripts will change when Fission will be enabled by default in FF96, which will be perceived as a bug by extension authors, hence my suggestion that it needs to be documented in https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_scripts and there should be some kind of public announcement for extension developers, probably, before Fission is enabled by default in FF96 (bug 1732358).

This behavior is actually already briefly described in the docs because that was already the case before Fission ([1]) , quoting it from the "Content script lifecycle during navigation" subsection part of https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Chrome_incompatibilities page:

In Chrome
Content scripts are destroyed when the user navigates away from a web page. If the user then returns to the page through history, by clicking the back button, the content script is injected into the web page again.

In Firefox

Content scripts remain injected in a web page after the user has navigated away, however, window object properties are destroyed. ...
To mimic the behavior of Chrome, listen for the pageshow and pagehide events. Then simulate the injection or destruction of the content script.

It may be reasonable to make this section "linkable" and link it also from https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_scripts to increase its visibility when a developer is looking for it in the doc page related to the content scripts.


[1]: quite some times ago react-devtools extension had an issue in Firefox which was related exactly to this chrome incompatibility, see https://github.com/facebook/react-devtools/pull/830

+1 to the above.

Also, since It looks like the previous behavior was a bug, you may mention it was fixed in the release notes for addon developers when Fission is fully enabled with a link to that info page.

Which previous behavior was a bug? This is exactly the way it worked before Fission (and currently works on Release).

Also BFCache is an optional performance optimization, not using it, reloading the page (and content scripts) when it's not available is also working as expected.

Which previous behavior was a bug?

Sorry, bad phrasing. The thing I'm trying to point out is the change itself because I'm worried it will affect many extensions, which didn't account for bfcache previously because it was (IMO) a super rare occurrence.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: