Closed Bug 945438 Opened 6 years ago Closed 6 years ago
Can't select menu items with mouse in Google's div-based select widgets
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.)
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.
Oh, and I still can select the item with keyboard.
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
Assignee: nobody → mbrubeck
Whiteboard: [beta28] p=0 → [beta28] p=3
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.
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.
It looks like the MouseEvent.buttons property is incorrectly set to 0 in Metro Firefox.
(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.
Forgot to qref, sorry.
https://hg.mozilla.org/integration/fx-team/rev/574faba0c776 An automated test for this bug landed separately in a patch from bug 957490.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: [beta28] [defect] p=3 [fixed-in-fx-team] → [beta28] [defect] p=3
Target Milestone: --- → Firefox 29
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.
Attachment #8356990 - Flags: approval-mozilla-aurora?
Attachment #8356990 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
For iteration #22, verified as fixed with latest Nightly and Aurora on Win 8.1 64-bit, by using the STR from comment 0.
> 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.
You need to log in before you can comment on or make changes to this bug.