1342569 - mouseenter/mouseleave fire differently on <select>s in e10s mode.

Status: NEW

(Core :: DOM: Events, defect, P2)

Description

[Thomas Wisniewski]

It seems that <select>s and their dropdowns are considered separate objects in e10s mode, for the purposes of determining when to fire mouseenter/mouseleave events. In a non-e10s window the <select> *and* its dropdown are both counted as one object.

You can see this in effect in the attached testcase by comparing when the events are fired between an e10s and non-e10s window.

This is breaking the quality menu option on clips.twitch.com as per the given URL (as reported in webcompat.com issue #4697).

Comment 1

[Thomas Wisniewski]

Attachment: testcase.html

Just attaching the aforementioned test-case.

Comment 2

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Mike is probably in the best position to fix or investigate this.

Comment 3

[Mike Conley (:mconley) (:⚙️)]

I'll try to look at this this week.

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 1342569 - Make sure <select> gets mouseenter and mouseleave events when select popup is entered and left.

Review commit: https://reviewboard.mozilla.org/r/118764/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/118764/

Comment 5

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 1342569 - [WIP] Attempt at a regression test.

Review commit: https://reviewboard.mozilla.org/r/118766/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/118766/

Comment 7

[Astley Chen (inactive)]

HsinYi, is it something your team can keep it up and running?

Comment 8

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Ben, please help this after another similar (?) bug 1296264. Thanks.

Comment 9

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 10

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 11

[Mike Taylor [:miketaylr]]

Note: the twitch bug that was reported seems invalid now -- it's working for me, likely due to a site redesign.

Comment 12

[caseycabrales]

Is this bug going to be addressed or is there another issue I can follow? It's still a problem with the same reproduction steps as in this issue and the duplicate https://bugzilla.mozilla.org/show_bug.cgi?id=1296264. Any viable workarounds in the meantime?

Also FWIW it's still an issue on twitch.tv, just in the "Report Playback Issue" menu option instead of quality.

Comment 13

[Karl Dubost💡 :karlcow]

This might be another case
https://github.com/webcompat/web-bugs/issues/101110

Comment 14

[Emilio Cobos Álvarez (:emilio)]

Mike, do you have context on why the setCapture approach didn't work?

Comment 15

[Karl Dubost💡 :karlcow]

Attachment: test case for mouseenter, mouseleave and mouseout

With the testcase

Hovering the select button and stay

mouseenter: yes on Gecko, Blink, WebKit

Hovering the select button and leaving

mouseenter: yes on Gecko, Blink, WebKit
mouseleave: yes on Gecko, Blink, WebKit
mouseout: yes on Gecko, Blink, WebKit

Hovering the select button and CLICK without moving

mouseenter: yes on Gecko, Blink, WebKit
mouseleave: yes on Gecko
mouseout: yes on Gecko

Note that Moving the cursor will keep firing events on Gecko.
The mouseleave and mouseout events are fired only when releasing the widget after selection

in video
https://imgur.com/a/XUQTMUg

Comment 16

[Karl Dubost💡 :karlcow]

To note that in case of https://github.com/webcompat/web-bugs/issues/101110
it breaks the site because of

$('.smbDropdown').mouseout(function () {
  this.blur()
});

Comment 17

[Karl Dubost💡 :karlcow]

Hsin-Yi,
I would be tempted to raise the severity of this. When a site use a feature like the one in Comment #16 it makes Firefox really unusable for this site. The Webcompat Priority is low as we have not detected a lot of sites breaking and a big site breaking, but when the breakage is happening, this is bad for the user.

Comment 18

[Dennis Schubert [:denschub]]

This is breaking functionality on some sites. Twitch fixed it, and the other known cases are lower priority, so setting WebCompat priority P2 for now.

Comment 19

[Mike Conley (:mconley) (:⚙️)]

Attachment: WIP: Bug 1342569 - Try to capture events on <select> when the panel is open.

Comment 20

[Mike Conley (:mconley) (:⚙️)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #14)

Mike, do you have context on why the setCapture approach didn't work?

I don't, but when I revived the patch (which I've attached as a WIP) and updated it to use setCaptureAlways (https://searchfox.org/mozilla-central/rev/1ca8ea11406642df4a2c6f81f21d683817af568d/dom/webidl/Element.webidl#144-149), it didn't seem to solve the issue.

I'm not really sure how to proceed with this. Is there some platform mechanism I can use to suppress event handling by the in-content <select> control until the dropdown is closed? I looked at https://searchfox.org/mozilla-central/rev/1ca8ea11406642df4a2c6f81f21d683817af568d/dom/interfaces/base/nsIDOMWindowUtils.idl#972-979, and while that kind of works as a replacement to setCaptureAlways, it also just ends up deferring events for the entire document until the suppression ends, which probably isn't what we want.

I guess I could add a capturing event handler in the SelectChild script for a bunch of events and just prevent them from propagating down to the <select>... is there a better way?

Comment 21

[Emilio Cobos Álvarez (:emilio)]

I'm not super familiar with how we do the mouseout event when we move from the <select> to the popup, and whether there'd be a good way to prevent it from firing... I could try to look into it, but maybe Edgar knows off-hand? Edgar, see comment 20 and comment 14 for context. Thanks!

Comment 22

[Edgar Chen [:edgar]]

The mouseout event is triggered from parent process when the mouse moves from <browser> into the popup. Using setCaptureAlways doesn't work, I think it is because of it only set the mouse capture on the process where the setCaptureAlways is called (content process in this case), so the parent process still generate the mouseout event. And I don't think setting capture also in parent help, because popup would not be able to receive the mouse event if we set capture on <browser>.

I test on Chrome and Safari, the web content document doesn't receive mousemove event when the popup is opened. It seems like they suppress the mouse event?

(In reply to Mike Conley (:mconley) (:⚙️) from comment #20)

I looked at https://searchfox.org/mozilla-central/rev/1ca8ea11406642df4a2c6f81f21d683817af568d/dom/interfaces/base/nsIDOMWindowUtils.idl#972-979, and while that kind of works as a replacement to setCaptureAlways, it also just ends up deferring events for the entire document until the suppression ends, which probably isn't what we want.

Maybe we could add a way to suppress only mouse event?