This page for example (also happens on other pages), wait for the Phabricator Revisions to load and then click one of the Phabricator Revision. Wait for the Phabricator page to load. Now click the back-button.

Actual:
It seems that the content script is not loaded into the (cached)? page.

Expected:
The content script should be loaded into the page (in chrome it works as expected).

This is the expected behavior. Content scripts get loaded into a document once. When you go back to a page in bfcache, the content scripts are already loaded, so they don't get loaded again. If you want to do something special in those cases, you need to add a "pageshow" listener.

(In reply to Kris Maglione [:kmag] from comment #1)

so they don't get loaded again.
I need to load the jquery.min.js script into the cached page again?
Because, it doesn't seem to stay loaded in the cached page!

Sorry, it should be:

so they don't get loaded again.

I need to load the jquery.min.js script into the cached page again?
Because, it doesn't seem to stay loaded in the cached page!

the content scripts are already loaded

The jquery.min.js script does not stay loaded in the cached page.

If you have a testcase that shows the problem, I can look at it, but the testcase you posted works as expected.

The jquery.min.js script is still cached, but the jQuery property on the window is not available anymore.

Is this a bug or is this the expected behavior?

STR:

1. Open https://bugzilla.mozilla.org/show_bug.cgi?id=1524687
2. Open devtools console
3. Open a https://phabricator.services.mozilla.com/* link and watch for message by the test add-on
4. Now go back (using back-button) and watch again for message

STR:

1. Load attached extension.
2. Visit https://example.com
   (the content script will assign a value to window.prop1, this.prop1 (this = content script global) and document.prop3)
3. Visit anything else, e.g. by clicking the link to iana.org
4. Navigate back to example.com
5. Open the console for the tab and look at the printed messages.

Expected:

• At step 2, 3 and 4 the values of window.prop1, this.prop1 and window.prop2 should be printed.

Actual:

• At step 2 and 3, the expected values are printed (at the start of the content script execution, and upon pagehide).
• At step 4, the value of window.prop1 has become undefined (after pageshow).

Full log demonstrating the issue, captured in Firefox Nightly 67.0a1 buildID 20190211092917

[https://example.com/ Mon Feb 11 2019 18:28:41 GMT+0100 (Central European Standard Time)] contentscript executed for the first time
window.prop1 = window.prop
global.prop2 = global.prop
global.prop1 = window.prop (inherit from window)
document.prop3 = document.prop
contentscript.js:17:5
[https://example.com/ Mon Feb 11 2019 18:28:41 GMT+0100 (Central European Standard Time)] pagehide
window.prop1 = window.prop
global.prop2 = global.prop
global.prop1 = window.prop (inherit from window)
document.prop3 = document.prop
contentscript.js:17:5
[https://example.com/ Mon Feb 11 2019 18:28:41 GMT+0100 (Central European Standard Time)] pageshow
window.prop1 = undefined
global.prop2 = global.prop
global.prop1 = undefined (inherit from window)
document.prop3 = document.prop

This is a valid bug and needs more investigation.

Boris, your thoughts on this one?

Found related bug 1404107. Jason, can you look into this?

So the basic structure here is like so. We start with a Window W1 which has a WindowProxy P1. There is an Xray X1 to it, which points at the WindowProxy.

Now we navigate. This creates a new Window W2 and a new WindowProxy P2. P1 mutates into a cross-compartment wrapper to P2. All CCWs are recomputed and X1 becomes an Xray pointing to P2. The old contents of the X1 object (including expandos) are thrown away; they can't stay on the object, because it now represents a new window and that should not have the same expandos.

Then we navigate back. The current window becomes W1 again. P1 becomes its WindowProxy again. P2 becomes a CCW to P1. We recompute CCWs again, and X1 becomes an Xray pointing to P1. But the expando state is gone.

In terms of fixing this, probably the sanest thing is for WindowStateHolder to store all the Xray expando objects for the window. Then we can restore them after we do the xpc::TransplantObject in nsGlobalWindowOuter::SetNewDocument (which is what does the wrapper remapping).