Closed Bug 1607375 Opened 5 years ago Closed 4 years ago

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

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla78
Fission Milestone M6a
Tracking Status
firefox78 --- fixed

People

(Reporter: mccr8, Assigned: edgar)

References

(Blocks 1 open bug)

Details

Attachments

(3 files, 2 obsolete files)

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.

Fission Milestone: --- → ?

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

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

Tracking for Fission dogfooding (M5)

P1 because this is a major user annoyance.

Fission Milestone: ? → M5
Priority: -- → P1

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?

Flags: needinfo?(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.

Flags: needinfo?(hsivonen)

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.

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.

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.

Fission Milestone: M5 → M6
Flags: needinfo?(continuation)

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.

Flags: needinfo?(continuation)
Summary: [Fission] Video controls on Twitch don't always appear on mouse over → [Fission] Video controls on Twitch don't always appear on mouse over (on streams with a Twitch Extension?)

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

Fission Milestone: M6 → ?

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

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

Assignee: nobody → nika
Fission Milestone: ? → M6
Attached file mouseenter_oop_subframe.html (obsolete) —

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.

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

Attachment #9129887 - Attachment is obsolete: true

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?

Assignee: nika → nobody
Flags: needinfo?(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.

Flags: needinfo?(hsivonen)
See Also: → 1619370

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)?

Flags: needinfo?(bugs)

(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.
Assignee: nobody → echen

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.

Tentatively moving P1 Fission M6 bugs to M6a.

Fission Milestone: M6 → M6a

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

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

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.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Attachment #9134278 - Attachment is obsolete: true

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

The attached test case does work for me, though.

Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

(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.

(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.

Set pointer-events to auto could reproduce similar behavior.

log the mousemove event for comparing behaviour between browsers.

Attachment #9143926 - Attachment is obsolete: true
Attachment #9134278 - Attachment is obsolete: false
Attachment #9134278 - Attachment description: Bug 1607375 - The chrome process needs to dispatch UI events to the process of browsing context ancestors of target iframe; → Bug 1607375 - Generate mouse exit event to old remote target when the mouse event is moving to another remote target;

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

(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

Pushed by echen@mozilla.com:
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
Regressions: 1637132
Status: REOPENED → RESOLVED
Closed: 4 years ago4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla78
Regressions: 1650657
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: