1607375 - [Fission] Video controls on Twitch don't always appear on mouse over (on streams with a Twitch Extension?)

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P1)

Description

[Andrew McCreight [:mccr8]]

If you watch a video on https://www.twitch.tv/ then when you move your mouse over the video (you don't need to click) some video controls are supposed to appear (showing things like a button to pause, adjust the volume, etc.). When Fission is enabled, these video controls don't always appear.

If I move the mouse cursor from outside of the video window to over the video window very slowly, the controls seem to mostly appear, but if I rapidly move the mouse cursor from outside of the window to inside the window, then the video controls usually don't appear, even if I then move the mouse cursor around on the video slowly. In a non-Fission-enabled window, the video controls appear consistently in both cases.

I'm filing this in UI Events because maybe there's an issue with event handling under Fission, but that's just a guess.

Comment 1

[Andrew McCreight [:mccr8]]

For what it is worth, this is the main non-crash annoyance I have with Fission right now.

Comment 2

[Andrew McCreight [:mccr8]]

I think I see similar behavior on YouTube, but I hit it much less frequently.

Comment 3

[Chris Peterson [:cpeterson]]

Tracking for Fission dogfooding (M5)

P1 because this is a major user annoyance.

Comment 4

[Nika Layzell [:nika] (ni? for response)]

I think this might be related to Henri's work on getting focus to work properly with Fission. Henri, do you know what might be causing this issue, and whether your ongoing work might help with it?

Comment 5

[Henri Sivonen (:hsivonen)]

(In reply to :Nika Layzell (ni? for response) from comment #4)

I think this might be related to Henri's work on getting focus to work properly with Fission. Henri, do you know what might be causing this issue, and whether your ongoing work might help with it?

This is about hovering rather than clicking, so, superficially, this shouldn't be related to the SetFocus bug.

Comment 6

[Andrew McCreight [:mccr8]]

I need to come up with some better STR. I can't reproduce this when I open Twitch in a private browsing window, so there might be some interaction with some Twitch feature that is only enabled when you are logged in.

Comment 7

[Andrew McCreight [:mccr8]]

It seems to reproduce more often if you first click on the title below the video, then rapidly move the mouse over the middle of the video screen.

Comment 8

[Chris Peterson [:cpeterson]]

Andrew, can you still reproduce this Twitch bug?

Tracking for Fission Nightly (M6) because no one in the Fission triage meeting can reproduce it. It might still be a bug, but it is not common.

Comment 9

[Andrew McCreight [:mccr8]]

Yes, I still see this all of the time. It only seems to affect some streams. Maybe it only affects streams that have certain Twitch Extensions turned on? The extensions function as overlays, so that could affect how hovering works. For instance, right now streams with the Path of Exile Armoury Extension seem to trigger the issue, while other ones with only some kind of Amazon Prime overlay message don't seem to.

I went through the top 5 Path of Exile streams on this list, and 4 of them had the Armoury extension enabled, and I was getting the bug on those four. The fifth one did not have it enabled, and was also not showing the bug. Same thing in a fresh profile. A couple of other streams for other games that I tried that did not have extensions worked just fine.

Comment 10

[Andrew McCreight [:mccr8]]

I have better STR now, so maybe it is worth reconsidering for triage? I don't know what % of Twitch streams have extensions.

Comment 11

[Andrew McCreight [:mccr8]]

I didn't have WebRender enabled before, but enabling it didn't fix the issue for me.

Comment 12

[Chris Peterson [:cpeterson]]

Nika reproduced this a few days ago. Looks like hover events need to pass through multiple cross-origin iframes?

Assign to Nika to find minimal STR. She will then send back to triage or reassign to someone else.

M6

Comment 13

[Nika Layzell [:nika] (ni? for response)]

Attachment: mouseenter_oop_subframe.html

Attaching a test case which manages to reproduce the issue for me. Mousing over the iframe should fire "mouseenter" and "mouseleave" events on the surrounding <div> element, but with fission they are sometimes not fired, and sometimes fired inconsistently at large intervals.

Comment 14

[Nika Layzell [:nika] (ni? for response)]

Attachment: mouseenter_oop_subframe.html

Accidentally used "http://" instead of "https://", causing the mixed content blocker to get annoyed when hosted on bugzilla.

Comment 15

[Nika Layzell [:nika] (ni? for response)]

Unassigning now that I've created a reduced testcase.

:hsivonen, do you happen to know what might be causing this behaviour with the "mouseenter" and "mouseleave" events?

Comment 16

[Henri Sivonen (:hsivonen)]

(In reply to :Nika Layzell (ni? for response) from comment #15)

:hsivonen, do you happen to know what might be causing this behaviour with the "mouseenter" and "mouseleave" events?

I don't know. The dispatch happens based on APZ, so perhaps a targeting change on the APZ level happens to skip over some layout-level test that would normally trigger the events.

Comment 17

[Henri Sivonen (:hsivonen)]

I'm failing at searchfox. smaug, where are we we supposed to make the decision to generate layout-level mouseenter/leave (as opposed to mouse entering and leaving the native widget)?

Comment 18

[Olli Pettay [:smaug][[e-mail]]]

Look for EnterLeaveDispatcher
https://searchfox.org/mozilla-central/rev/7d0c94a0e9a9fe1f83553f49b10128567d21709d/dom/events/EventStateManager.cpp#4279
https://searchfox.org/mozilla-central/search?q=symbol:T_mozilla%3A%3AEnterLeaveDispatcher&redirect=false

Comment 19

[Edgar Chen [:edgar]]

(In reply to :Nika Layzell (ni? for response) from comment #14)

Created attachment 9129888 [details]
mouseenter_oop_subframe.html

What I observe is

• When I move the mouse and stop over the iframe, the mouseenter and mouseleave are both fired at small intervals after stop moving.
• But if I move the mouse cursor cross the iframe and stops outside the iframe, then no event is fired.

Comment 20

[Edgar Chen [:edgar]]

Summary what I found:
1). When mousing over the iframe, the parent process only delivers 'mousemove' event to the oop-iframe process. So there is no corresponding mousemove event fired on topmost child process. This also happens for other UI events, too, like keyboard events.
2). Because of 1), the catched mouse location doesn't be updated correctly in the topmost child process and cause it synthesizes mousemove event on an incorrect point which generates an unexpected mouseleave.

Comment 21

[Edgar Chen [:edgar]]

Attachment: Bug 1607375 - Generate mouse exit event to old remote target when the mouse event is moving to another remote target;

Comment 22

[Chris Peterson [:cpeterson]]

Tentatively moving P1 Fission M6 bugs to M6a.

Comment 23

[Edgar Chen [:edgar]]

Strange, I could not reproduce this any more on recent nightly.

Comment 24

[Edgar Chen [:edgar]]

8:37.69 INFO: First good revision: 02639d0327aa82d8bfd45a1c634ffe02a8d249d2
8:37.69 INFO: Last bad revision: 502e83464c91a6be88fb524c1378799e19e32101
8:37.69 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=502e83464c91a6be88fb524c1378799e19e32101&tochange=02639d0327aa82d8bfd45a1c634ffe02a8d249d2

Comment 25

[Edgar Chen [:edgar]]

It looks like something related to WR actually, and this issue didn't happen at all if the WR isn't enabled. And bug 1566599 seem like making the WR and non-WR behave the same on hit-testing.

Comment 26

[Andrew McCreight [:mccr8]]

I still see this issue on Twitch as described in comment 9.

The attached test case does work for me, though.

Comment 27

[Edgar Chen [:edgar]]

(In reply to Andrew McCreight [:mccr8] from comment #26)

I still see this issue on Twitch as described in comment 9.

Yeah, I could also reproduce this issue now.
I found that if I move the mouse from the "Stream Chat" on the right side or the title below the video to the video, it works fine. That is why I think this issue is fixed.

But if I move the mouse from the channel list on the left side to the video, I could reproduce this issue consistently.
The channel item is still highlighted like the mouse is still over on it.

Comment 28

[Edgar Chen [:edgar]]

(In reply to Edgar Chen [:edgar] from comment #27)

But if I move the mouse from the channel list on the left side to the video, I could reproduce this issue consistently.
The channel item is still highlighted like the mouse is still over on it.

I noticed that the video area receives mouseenter and mouseleave repeatedly, like

mouseenter pageX:369 pageY:265
mouseleave pageX:34 pageY:234
mouseenter pageX:410 pageY:267
mouseleave pageX:34 pageY:234
mouseenter pageX:296 pageY:261
mouseleave pageX:34 pageY:234
mouseenter pageX:242 pageY:174
mouseleave pageX:34 pageY:234
mouseenter pageX:393 pageY:221
mouseleave pageX:34 pageY:234

And it looks like all mouseleave is generated on the same position.

Comment 29

[Edgar Chen [:edgar]]

Attachment: (pointer-events:auto) mouseenter_oop_subframe.html

Set pointer-events to auto could reproduce similar behavior.

Comment 30

[Edgar Chen [:edgar]]

Attachment: (pointer-events:auto) mouseenter_oop_subframe.html

log the mousemove event for comparing behaviour between browsers.

Comment 31

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/#/jobs?repo=try&group_state=expanded&revision=7ebf06a36071d3be5d617a767a0e76541078a28d

Comment 32

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a549beacbe3b550e4076bd730d9e674003b83b7d

Comment 33

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=86483c202b806100a968d7a7be8338b13ab9d8d7

Comment 34

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=946b927e5052e7fe3f80f3f9e0b8245c92854115

Comment 35

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a0c5ca4d3929c00156c034b910241d12e695920f

Comment 36

[Edgar Chen [:edgar]]

Hmm, strange, test got timed out on Linux and Window on try, but I did not see the same thing on my local Linux.

Comment 37

[Edgar Chen [:edgar]]

(In reply to Edgar Chen [:edgar] from comment #36)

Hmm, strange, test got timed out on Linux and Window on try, but I did not see the same thing on my local Linux.

It is because of https://searchfox.org/mozilla-central/source/dom/events/test/test_event_screenXY_in_cross_origin_iframe.html that ran before the new added test already moves the mouse to a certain area, so we don't get mouseenter event. Fixed.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=d723fb3cdc8b2a51e107ec8732be7c69c0662436&group_state=expanded

Comment 38

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/eaadf10e4478
Generate mouse exit event to old remote target when the mouse event is moving to another remote target; r=hsivonen,smaug

Comment 39

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/eaadf10e4478