(1 attachment)

For now, content scripts were only destroyed/detached when the matched document was removed from bfcache, so that it will still be alive and working if we get back to this document. (And it won't be created twice: one on page loading, and another time when we browse back to this document in history)
This choice introduce a quite important issue. When the user goes back or forth in history, the content script will still "work" on websites that don't necessary match page-mod rules. By working I mean that the script can still fire timeouts, interval, messages, events and eventually listen to some DOM events.
I think that we will have to introduce some specifics in order to handle nicely the history usecase. We do want to keep content script around until the document is removed from bfcache, mainly to avoid cases where we would apply a content twice to the same document instance. For ex, when we go back and immediatly forth in history.
So we want to keep it "around", but like documents in bfcache, we do want to freeze the content script so that timeouts and events are temporarily disabled.
It will allow to pause any computation made by the content script if the matched document is hidden and has the side effect to avoid any access to other documents in history!
We may want to be extra safe about this particular point. We may want to ensure that content script can only have access to inner window object. So that it will never to able to get access to other windows in history.
Last but not least, it would allow us to offer a way better support in page-mod for content script that need to have specific behavior between page being hidden/showed from history, and, page being destroyed (tab/window close).

This patch introduce 3 new events on content script side: detach, pageshow, pagehide.
- pagehide is fired when the user open a link, or go back/forward in history. The related document is kept in bfcache and may still be shown later on.
- pageshow: is fired when the related document is shown again. i.e. when the user go back or forward in history and open up this document again.
- detach: is fired when the document is destroyed. i.e. removed from bfcache. The content script is totally destroyed so that it should stop any possible activity, as the related document is destroyed too and won't be available anymore. It mainly happens when the tab/window is closed.
pageshow and pagehide are dispatched on addon side too.
You can listen to these events with:
self.on("pageshow", function onPageShow() { ... }); // from content script
worker.on("pagehide", function onPageHide() { ... }); // from addon module
Then, this patch freeze the content script on pagehide and unfreeze it on pageshow.
It basically reproduce what is done for the document itself: all setTimeout and setInterval are disabled during the freeze and restored on unfreeze. All DOM events should be disabled as well, but at first sight, there is no need to do that, the platform does this for us. It isn't done for timers as we are *not* using document ones. Finally we only have to disable message/event API (postMessage/emit).
I've decided in this patch to print warning messages when the addon try to send messages to a frozen content script, but we may decided to either throw exception, do nothing, or keep message until content script is alive again?

The description of this in the release notes, at
https://wiki.mozilla.org/Labs/Jetpack/Release_Notes/1.9
says
"Content scripts are only destroyed/detached when the matched document is removed from the bfcache, so that it will still be alive and working if we get back to this document. (And it won't be created twice: once on page loading, and another time when we browse back to this document in history).
This choice introduce a quite important issue. When the user goes back or forth in history, the content script will still "work" on websites that don't necessary match page-mod rules. Meaning that the script can still fire timeouts, interval, messages, events and eventually listen to some DOM events. "
I thought the plan was that this would PREVENT content scripts from being applied to web sites that don't match the page-mode rules. Are the release notes wrong?

(In reply to John Nagle from comment #3)
> I thought the plan was that this would PREVENT content scripts from being
> applied to web sites that don't match the page-mode rules. Are the release
> notes wrong?
It didn't went into 1.9. It is listed in "Known issues" list. So that it describe the current broken behavior.