1081691 - [e10s] 'mouseover' and 'mouseout' events don't work correctly for <browser> element or remote <browser> element

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[dw-dev]

I am currently migrating my 'Tile Tabs' add-on to e10s windows, and I need to listen for 'mouseover' and 'mouseout' events on <browser> elements.

If I add event listeners for the 'mouseover' and 'mouseout' events to a <browser> element in the chrome process, then when the events occur event.currentTarget returns CPOW [object ContentFrameMessageManager]] instead of the <browser> element.

If instead, I add event listeners for the 'mouseover' and 'mouseout' events in the content process framescript and send messages to the chrome script, everything works fine unless the content document is 'about:blank', in which case the event listeners are only called the first time the events occur.

I need a solution where event.currentTarget always returns the <browser> element and which works for all content documents.  Any ideas?

Comment 1

[dw-dev]

Just to clarify, when the listeners are in the chrome process, event.currentTarget returns [object CPOW [object ContentFrameMessageManager]].

Comment 2

[Chris Peterson [:cpeterson]]

https://addons.mozilla.org/en-US/firefox/addon/tile-tabs/

btw, some of the about: pages currently run in the chrome process, which might explain the about:blank problem you saw.

Comment 3

[dw-dev]

Good catch! The problem is related to which process the 'about:blank' <browser> element has been created in.

Tile Tabs sometimes has to create additional 'about:blank' tabs and the <browser> elements were being created in the content process.  After creating these tabs, I now call gBrowser.updateBrowserRemoteness(tab.linkedBrowser,false) and this fixes the problem.  So this bug can be closed.

However, while investigating this problem, I found a bug in Firefox.  If you set the Firefox homepage to 'about:blank', then when Firefox starts up the initial tab is created in the content process, rather than in the chrome process.

Comment 4

[dw-dev]

Please ignore my previous comment completely.

Looking at the Firefox source code, it appears that 'about:blank' tabs will always be created in a remote browser in the content process, which is what happened when Tile Tabs called gBrowser.addTab().

In this case, the 'mouseover' and 'mouseout' event listeners in the framescript are only called the first time the events occur, as originally reported.

Comment 5

[dw-dev]

I've done some more investigation in the scenario where I add event listeners for the 'mouseover' and 'mouseout' events to a <browser> element in the chrome process.

In this scenario, when a 'mouseover' or 'mouseout' event occurs, the listener is called twice:
- first with event.currentTarget set to the <browser> element.
- second with event.currentTarget set to [object CPOW [object ContentFrameMessageManager]].

By using the first call and discarding the second call, I can do what I need to do.

Comment 6

[David Parks [:handyman]]

(In reply to dw-dev from comment #5)
> In this scenario, when a 'mouseover' or 'mouseout' event occurs, the
> listener is called twice:
> - first with event.currentTarget set to the <browser> element.
> - second with event.currentTarget set to [object CPOW [object
> ContentFrameMessageManager]].

Its been a while... are you still having these issues?  After digging into this, it sounds like you might be having the same issues as this person:

http://forums.mozillazine.org/viewtopic.php?f=19&t=2892611

who was able to fix it with the multiprocessCompatible addon config setting (which might require other addon work):

https://developer.mozilla.org/en-US/Add-ons/Install_Manifests#multiprocessCompatible

The compat shims are generating 'extraneous' compatibility messages as it believes you are not multiprocess aware... I think.  So, comment 5 was on the right track but was missing this piece.

Comment 7

[dw-dev]

After I wrote comment 5, I did a lot more digging and testing, which confirmed what I said about the listener being called twice for each event.  I also found the mozillaZine forum post that you have referenced in comment 6, which again confirmed the behaviour I was seeing.

To make my code more robust, rather than just discarding the second call to the listener, I now test the received events using Components.utils.isCrossProcessWrapper(event.originalTarget) and discard any events for which this is true. 

The approach I have taken with Tile Tabs and Tile View (and all my other add-ons) when migrating them to e10s is to implement messaging between the chrome and remote browser processes for frequent and/or intensive operations.  For occasional cross-process references, I have relied on the compatibility shims (unless testing revealed timing issues).

At present, I do not have the time to completely remove the dependency on the compatibility shims, so that my addons could be marked as "multiprocessCompatible" - and in any case, this would make the code more convoluted and less readable. 

Tile Tabs and Tile View (and all my other add-ons) now work reliably with multiprocess Firefox [e10s], although I am still waiting for the drag-and-drop functionality to be fully implemented.

Comment 8

[David Parks [:handyman]]

Attachment: bootstrap.js for addon

Im missing something here.
dw-dev, does this addon code register on the element the way that you expect?  I've tried this (which sets tab #0 to about:blank and logs mouseout events) in an e10s window on mac and Win8 and I never see a CPOW event logged to the Browser Console window -- only event.currentTarget == [object XULElement].  Do you know what's missing?

Comment 9

[David Parks [:handyman]]

Attachment: test addon to log mouseout events

Comment 10

[dw-dev]

David,

The event listeners must be added in the chrome process.  The web page must be loaded in a remote browser.

The code that 'Tile Tabs' uses is essentially as follows:

        browser = tab.linkedBrowser;
        browser.addEventListener("mouseover",tileTabs.onMouseOverBrowser,true);
        browser.addEventListener("mouseout",tileTabs.onMouseOutBrowser,true);

And in the onMouseOverBrowser() and onMouseOutBrowser() event listeners, I have the following workaround:

        if (tileTabs.ffVersion >= +"34.0" && Components.utils.isCrossProcessWrapper(event.currentTarget)) return;

Will "about:blank" be loaded in the chrome process or a remote process?

With regards to your test conditions, my experience is that in a few instances, usually immediately after Firefos starts up, tab #0 appears to perform differently to subsequent tabs.

I guess it is just possible that this problem has gone away since I last tested on 3rd March.  I could re-test if necessary?

Comment 11

[dw-dev]

As part of updating 'Tile Tabs' to keep in step with the latest e10s changes, I have done some retesting with Nightly 40.0a1 (2015-04-28). This included retesting the 'mouseover' and 'mouseout' event listeners that 'Tile Tabs' adds to <browser> elements in the the chrome process.

This testing showed that when a 'mouseover' or 'mouseout' event occurs:
- the event listener is sometimes still called twice. 
- event.currentTarget is always set to the <browser> element in the the chrome process and is now never a CPOW.

As far as I am concerned, this bug can now be closed.

Comment 12

[David Parks [:handyman]]

(In reply to dw-dev from comment #11)
> As far as I am concerned, this bug can now be closed.

This had dropped off my radar -- many thanks for circling back to it.  I agree with WFM.