Closed
Bug 766088
Opened 12 years ago
Closed 12 years ago
Content scripts are kept "alive" when going back/forward in history
Categories
(Add-on SDK Graveyard :: General, defect, P1)
Add-on SDK Graveyard
General
Tracking
(Not tracked)
RESOLVED
FIXED
1.11
People
(Reporter: ochameau, Assigned: ochameau)
References
Details
Attachments
(1 file)
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).
Assignee | ||
Comment 1•12 years ago
|
||
Assignee: nobody → poirot.alex
Assignee | ||
Comment 2•12 years ago
|
||
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?
Priority: -- → P1
Comment 3•12 years ago
|
||
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?
Comment 4•12 years ago
|
||
Did this go into SDK 1.9? And it's listed as a block for https://bugzilla.mozilla.org/show_bug.cgi?id=693345 which it was supposed to fix. What's the status here?
Assignee | ||
Comment 5•12 years ago
|
||
(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.
Assignee | ||
Comment 6•12 years ago
|
||
Comment on attachment 634493 [details]
Pull request 469
Erik, I was wondering if you were handling this corner case in scriptish?
What's your thoughts about such approach?
Attachment #634493 -
Flags: feedback?(evold)
Assignee | ||
Updated•12 years ago
|
Attachment #634493 -
Flags: feedback?(evold) → review?(evold)
Comment 7•12 years ago
|
||
Is this fixed in SDK 1.10?
Comment 8•12 years ago
|
||
Commits pushed to master at https://github.com/mozilla/addon-sdk https://github.com/mozilla/addon-sdk/commit/847d8fa873a257006fe5bb9917acfef36046eb5d Bug 766088: freeze content scripts when the page is hidden in history. https://github.com/mozilla/addon-sdk/commit/6d65a6e17cb46ae8ff51cf5fceed24f82ef5ec1e Merge pull request #469 from ochameau/bug/766088-freeze-content-scripts Fix Bug 766088: freeze content scripts when the page is hidden in history. r=@erikvold
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
Attachment #634493 -
Flags: review?(evold) → review+
Assignee | ||
Comment 9•12 years ago
|
||
(In reply to John Nagle from comment #7) > Is this fixed in SDK 1.10? Unfortunately, no. But a bunch of page-mod/content scripts improvement are going to be shipped in 1.11 release. You can get an overview of them here: http://test.techno-barje.fr/post/2012/09/16/1.11-page-mod-release/
Target Milestone: --- → 1.11
You need to log in
before you can comment on or make changes to this bug.
Description
•