945438 - Can't select menu items with mouse in Google's div-based select widgets

Status: VERIFIED FIXED

(Firefox for Metro Graveyard :: General, defect, P2)

Description

[Dmitrij D. Czarkoff]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20131202030201

Steps to reproduce:

1. Open any video on YouTube.
2. Scroll down to comments section.
3. Click on "Top comments" select widget (between the input field and comments) to get menu.
4. Select "Newest first".


Actual results:

Menu disappears as if I clicked elsewhere.


Expected results:

The comments section should get rebuild according to the selected option. (This happens in "desktop" instance of the same Nightly version.)

Comment 1

[Dmitrij D. Czarkoff]

Apparently the problem isn't limited to YouTube - I had it with other Google+ pages as well. G+ified YouTube is the easiest place to find it though. For me this bug is reproducible every single time I access G+ pages containing the widget.

Comment 2

[Dmitrij D. Czarkoff]

Oh, and I still can select the item with keyboard.

Comment 3

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

I thought that this might be related to bug 944362 but it doesn't seem to have anything to do with <select> elements. The <div> in question works with touch input (and with keyboard as noted in comment 2) but any clicks from the mouse appear to go through the element (I can click on links that are obscured by the item I'm trying to select).

Keeping the [triage] flag for now

Comment 4

[Matt Brubeck (:mbrubeck)]

There's a "mousedown" handler on some containing element (maybe the document) that hides the menu.  For some reason when clicking on the menu in Metro, the mousedown reaches this handler and causes the menu to hide before you can finish clicking it, though in Desktop it is consumed by the menu.

I thought this might be related to the fact that the menu is within an iframe, but even if I load just the comment frame (URI starting with https://apis.google.com/u/0/wm/4/_/widget/render/comments), it still fails in the same way.

I haven't had much luck debugging this; the minified inline scripts make it very hard to follow.  Next I'll see if I can repro the bug in a static copy of the page and then attempt to make a reduced test case.

Comment 5

[Matt Brubeck (:mbrubeck)]

Update: I cannot reproduce this using a static copy of the page because it does XHRs to fetch more scripts or something.  The JS code is generated or compiled in a way that makes it very difficult to figure out in a debugger.  By injecting my own mousedown listener, I see that the event propagates up to the document in both desktop and Metro, so rather than stopping propagation it must be using some other way of deciding whether the target was within the menu, but I don't know what that is or why it differs.

Comment 6

[Matt Brubeck (:mbrubeck)]

It looks like the MouseEvent.buttons property is incorrectly set to 0 in Metro Firefox.

Comment 7

[Matt Brubeck (:mbrubeck)]

Attachment: patch

(In reply to Matt Brubeck (:mbrubeck) from comment #6)
> It looks like the MouseEvent.buttons property is incorrectly set to 0 in
> Metro Firefox.

This is a thing that is true, but it is not actually related to this bug.  I filed bug 957490 to fix the "buttons" property.

It turns out the bug with Google menus happened because the "cancelable" property of the mousedown event was set to "false" when it should be "true".  This is set by the WidgetMouseEvent constructor.  We were constructing an NS_MOUSE_MOVE event and then morphing it into an NS_MOUSE_BUTTON_DOWN event, without updating the "cancelable" flag.

This patch fixes the bug by constructing the event with the right message from the start.

Comment 8

[Matt Brubeck (:mbrubeck)]

Attachment: patch

Forgot to qref, sorry.

Comment 9

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/integration/fx-team/rev/574faba0c776

An automated test for this bug landed separately in a patch from bug 957490.

Comment 10

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/574faba0c776

Comment 11

[Matt Brubeck (:mbrubeck)]

Comment on attachment 8356990 [details] [diff] [review]
patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Firefox for Metro

User impact if declined: Mouse clicks behave incorrectly on some pages

Testing completed (on m-c, etc.): On m-c since 01-09, including an automated test.

Risk to taking this patch (and alternatives if risky): Low-risk, Metro-only.

String or IDL/UUID changes made by this patch: None.

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/e54abcb18064

Comment 13

[Manuela Muntean [Away]]

For iteration #22, verified as fixed with latest Nightly and Aurora on Win 8.1 64-bit, by using the STR from comment 0.

Comment 14

[Manuela Muntean [Away]]

> For iteration #22, verified as fixed with latest Nightly and Aurora on Win
> 8.1 64-bit, by using the STR from comment 0.

Also verified with latest Nightly and Aurora on Win 8 64-bit.