1156616 - Extra frame scripts are created and never destroyed in e10s

Status: RESOLVED INVALID

(Firefox :: Untriaged, defect)

Description

[[e-mail]]

Attachment: Immortal Events.xpi

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:25.3) Gecko/20150323 Firefox/31.9 PaleMoon/25.3.1
Build ID: 20150323220253

Steps to reproduce:

Install the test case xpi on Nightly. Open the browser console (ctrl+shft+J not K). Right click in tabs and windows to observe the instances of frame scripts installed as in the following description:
Test Case Explanation:
The main thread script intends to load event listening frame scripts into every browser using the globalMM. The frame script has been simplified to report right mouse clicks in this case. Each instance of the frame script gets a random 4 digit id number to distinguish them. The frame scripts report their event capture in the main javascript console (ctrl+shift+J, not K) in the logging tab.

How it works with multiple tabs ( seems to be okay):
If you install this package on the latest nightly and open the console, you should see a single entry for each right mouse click. If you open a new tab, you should see the same thing with a different random id number. Return to a previous tab and its id number should persist. Each newly opened frame in each tab is getting a unique instance of the frame script. Each mouse event is trapped by only one frame script. This is working perfectly for me and makes sense and seems to fulfill what I suppose is mozilla's intention for frame scripts. If you close a tab and reopen another one, the original frame script is disposed and new instance, with new id number, is created...

How it works with multiple windows ( seems to be frame scipts and extra persistence of frame scripts ):
Now, open a new e10s window and repeat the excercise. I get _multiple_ frame scripts being activated which seems to be wrong. Furthermore, close the e10s window and right click in the original window. I see multiple frame scripts getting called, one of them is the original one attached to the tab and the other one is not the one from the new window but mysteriously created. Each tab in the original window will have them. This seems wrong since one event presumably should belong to only one frame script not to mention, what do the other instances attach to, if not a tab ???

Isn't this just harmless caching of old scripts:
I can tell you that this is not a harmless problem, it causes multiple call backs to the main thread and multiple actions for a single event in multiple /indepedent/ windows!
What it is not:
Looking at the code, you can see that I included stopPropagation and preventDefault to make it more clear that this is not the issue. return false is also included for good measure. none of these has any relation to the problem.

Why the documentation doesn't really describe the current behaviour:
I believe this related to the known bug that "frame scripts are cached forever" which is very briefly alluded to in the frame script tutorial.  "frame scripts are running forever" is a more accurate term. 

Please fix it and don't recommend some workaround:
The tutorial mentions something about deactivating them ( and I think deactivating the event listeners would be sufficient), but what exactly is the proper event to capture the frame closing and kill its listeners?



Actual results:

Multiple unwanted frame script instances are created when a new window is opened. Extra frame scripts are also created in the original window and persist even after the new window is closed. Multiple frame scripts are fed a single event since there are more than one in each browser element. See the entry above for details.


Expected results:

Each newly opened frame in each tab should get a unique instance of the frame script. This should also happen in each new tab created in a new window. Each mouse event is trapped by only one frame script in the currently active browser element because each browser element only has a single frame script attached to it. See the above entry for details.

Comment 1

[Blake Kaplan (:mrbkap) (inactive)]

Hi snuz,

I think that things are actually working as intended here. You're attaching an overlay to browser.xul, which will be attached to each browser window. Each time, you're creating a new (delayed) frame script that will be loaded in all processes. You should, instead, load your frame script on startup only and do per-window initialization in your overlay script.

Comment 2

[[e-mail]]

Yup, absolutely correct. I didn't know that browser.xul is run once per window. & I copied the pattern from a Mozilla tutorial. lol.

The best solution for an overlay based extension is just to use the windowMessageManager from browser.xul on initialization. This prevents the problem with no extra work.

If you have a bootstrap extension, then the you can call the globalMessageManager from bootstrap.js to get delayed frame script injection on each tab. There is no special per window initalization required per se, but you need some method to deactivate each frame script if the extension is disabled, updated or uninstalled.