Luís Miguel [:quicksaver] (not reading bugmail) Reporter
	Description • 9 years ago

(Before anything, let me know if you'd like me to try to get a more simplified test case, as I realize working directly with the add-on like this might not be optimal for you. And this requires such strict steps, I'm not sure I can even do it just like that... Anyway,)

Tested with latest version of The Fox, Only Better (https://addons.mozilla.org/firefox/addon/the-fox-only-better/) with latest Nightly in a clean profile with e10s enabled. The bug doesn't happen every time though, I usually have to restart the browser at least once after installing the add-on.

Short story: since the tab strip's empty space doesn't react to mouse events (so it can be used like a regular window's border for dragging and stuff), I listen to mouseout events for when the mouse leaves the reactive part of the window into that empty area, to simulate a sort of mouseover event on it.

Relevant code highlighted: https://github.com/Quicksaver/The-Fox--Only-Better/blob/master/resource/modules/slimChrome.jsm#L165-L200 . browserPanel = document.getElementById('browser-panel'), although I've also tested with 'tab-view-deck' and the results are the same.

I've attached a screencast showing how the UI's reacting to the mouse movement, and in it you can see that the toolbars don't appear as they should when the mouse is moved to the empty tab area. Mid-way through I open a non-e10s window to show how everything should always be working.

With some debugging through the console (added these messages in my local build, not on AMO), it's obvious that in the e10s window, whenever the mouse moves to the empty area, it seems to fire another mouseover event (onMouseReEnterBrowser), targeting the html node of the content document, which follows (and cancels) the original mouseout code (onMouseOutBrowser - onMouseOver). This doesn't happen in the non-e10s window.

Exact steps to reproduce:
1. Start e10s Nightly in clean profile
2. Install add-on, everything usually works for me at this point
3. Install Restartless Restart add-on (https://addons.mozilla.org/firefox/addon/restartless-restart/), it's just what I use to restart the browser
4. Surf back to about:home
5. Hit Ctrl+Alt+R to restart
6. Click anywhere in the page to dismiss the mini bar, let it hide and then move the mouse to the empty tab area
6.1 This step seems important to be done in that order for some reason. For example, if I hit any key before this, such as Ctrl+Shift+J to open the console before I move the mouse, the empty tab area will usually work correctly.

BTW, in the screencast you'll notice that I've hidden the small brighter area of the toolbars at the top, to simplify testing as it directly triggers the toolbars, bypassing the code above. You have to make sure that when you're moving the mouse up, it doesn't step-stop in there on its way up and goes directly to the empty tab area.

Ugh, talk about complex... Any thoughts?

	Mike Conley (:mconley) (:⚙️)
	Comment 1 • 9 years ago

Hey jimm,

Correct me if I'm wrong, but didn't you deal with some mouse event weirdness when passing the mouse to and from remote content? Would you know what might be happening here?

	Jim Mathies [:jimm]
	Comment 2 • 9 years ago

I fixed bug 1003934 which was actually related to tooltips, but fixed some event stuff with remote browsers. We still have M5 bug 1081691 which dparks has. I think that bug might be related more to this since it deals with mouse exit/leave events.

	Jim Mathies [:jimm]
	Comment 3 • 9 years ago

(In reply to Jim Mathies [:jimm] from comment #2)
> I fixed bug 1003934 which was actually related to tooltips, but fixed some
> event stuff with remote browsers. We still have M5 bug 1081691 which dparks
> has. I think that bug might be related more to this since it deals with
> mouse exit/leave events.

'mouse enter/leave events.'

	Luís Miguel [:quicksaver] (not reading bugmail) Reporter
	Comment 4 • 9 years ago

If I'm reading bug 1081691 correctly, it seems centered on some "less-than-perfect" compatibility shims dealing with mouse events in the content process. My add-on already has the multiprocessCompatible flag and should not be using any shims at all to work correctly in e10s (or at least none that I know of), especially since for this specific case it's reacting to events in the main window's DOM (as opposed to content DOM or even from <browser> elements) from within the chrome process directly.

My knowledge on those shims and how they're used/employed is very limited though, so I'm not sure if this is relevant or not. Just thought I should mention it either way because unless I'm missing something (which as I mentioned is very likely), bug 1081691 doesn't seem related, other than dealing with the same event types that is.

	Luís Miguel [:quicksaver] (not reading bugmail) Reporter
	Comment 5 • 9 years ago

So I can't reproduce this anymore it seems, although I'm not sure when it was fixed or by what bug. If it ever happens again I'll reopen.