1832341 - fission.webContentIsolationStrategy=0 breaks page history after reload

Status: UNCONFIRMED

(Core :: DOM: Content Processes, defect)

Description

[Andrey Lushnikov]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36

Steps to reproduce:

Using the fission.webContentIsolationStrategy=0 preference breaks reload.

Steps:

1. Create a /tmp/ff-profile folder

2. Put a single user.js file inside the folder with the following single line:

   user_pref('fission.webContentIsolationStrategy', 0);

3. Run stable firefox with -profile pointing to the /tmp/ff-profile folder:

   /Applications/Firefox.app/Contents/MacOS/firefox -profile /tmp/ff-profile

4. Navigate to any website, e.g. https://example.com

5. After the page loaded, reload it

Actual results:

Once the page is reloaded, a new history entry is added: you can see a "back" button activating after reload.

You can also see this by opening DevTools and checking the history.length value.

Expected results:

The history entry should not be added once a reload is hit.

---

NOTE: The fission.webContentIsolationStrategy is widely used to make CDP / remote fission-compatible.

Downstream bug: https://github.com/microsoft/playwright/issues/22640

Comment 1

[Olli Pettay [:smaug][[e-mail]] (vacation-ish -> Aug 1)]

peterv, does this ring any bells?
fission.webContentIsolationStrategy=0 should be like no-Fission, right?

Comment 2

[tobias]

I've also noticed that with webContentIsolationStrategy=0, a reload also removes any history that's in the forward state (i.e., after a reload the forward-button gets greyed out if it was previously clickable).

I've done a mozregression and (unsurprisingly) landed on https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2bd46b2573e6e52f396483be1822021b475deb70&tochange=a72096bff057d469bf02132d723af1091f19f728, which includes the commit of Bug 1723797, which introduced this pref. When running the broken nightly (2021-09-08), toggling webContentIsolationStrategy while fission.autostart=true also toggles the bug described here.

Comment 3

[Jens Stutte [:jstutte]]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #1)

peterv, does this ring any bells?
fission.webContentIsolationStrategy=0 should be like no-Fission, right?

Not exactly but mostly according to nika's comment here.

There seem to be some checks for fission.autostart that maybe might better look for the isolation strategy ( this one for workers at least looks suspicious to me )? Is this affected by SHIP being enabled or not regardless of the isolation settings ?

Comment 4

[Jens Stutte [:jstutte]]

Downstream bug: https://github.com/microsoft/playwright/issues/22640

has been closed by a work around. That does not make the assumed underlying problem go away on our side, of course.

It may be that if we want to really support this combination of settings, we should run some complete test suites with it? FWIW, there seem to be a few specific tests that explicitly set it to other values, but I do not think that those provide sufficient coverage.