Closed Bug 944362 Opened 6 years ago Closed 6 years ago
Scrolling a <select> element causes mouse events on that element to have wrong y coordinates
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release) Build ID: 20131127030201 Steps to reproduce: 1. open "https://bugzilla.mozilla.org/query.cgi" at 1366x768 resolution (so that "OS" select widget appears on the second row); 2. use scrollbar of that widget; 3. select a value with mouse pointer. Actual results: Wrong widget is activated. Instead of selecting n-th visible row of "OS" select widget I selected something else (most frequently something from the "Version" widget, though other elements, or even tabs, get randomly selected). Expected results: The row right under the mouth gets selected.
hmm, I can't reproduce. I scrolled down (using the mouse) and selected "Webtools Graveyard" at the very bottom. This is what was selected in the drop down after the menu was hidden.
Actually, I described it wrong. I hit the bug when I choose "Advanced search" and expanded "Detailed Bug Information" there, so that I get a set of <select multiple> widgets. The one with caption "OS" doesn't fit the row; this is the widget that causes problems for me.
Verified. Used following steps: 1. Browsed to https://bugzilla.mozilla.org/query.cgi 2. Set screen resolution low enough so that "Hardware" and "OS" in "Advanced Search" appear on a second row. 3. Scrolled the "OS" <select> box 4. Attempted to click items in the "OS" <select> box Each click seemed to be offset by some amount in the y-direction. By clicking in the "OS" box, I was able to expand the "Comment" box, focus the "Bugs numbered" text box, and select the string "(comma-separated-list)" Marking as block28 - this is pretty seriously wrong behavior. We can move to release28 if we have to.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [triage] → [block28]
(In reply to Tim Abraldes [:TimAbraldes] [:tabraldes] from comment #3) > Each click seemed to be offset by some amount in the y-direction. In my experience the offset may change randomly - I even managed to switch tabs by doing this.
Summary: Scrolling select elements changes the input focus → Scrolling a <select> element causes mouse events on that element to have wrong y coordinates
Apparently I hit this bug with transmission webui too - scrolling list of torrents progressively offsets "y" coordinate of mouse clicks.
Assignee: nobody → spohl.mozilla.bugs
Status: NEW → ASSIGNED
Whiteboard: [beta28] p=0 → [beta28] p=3
Setting layers.draw-border to true revealed that the apz didn't seem to get scroll udpates for the <select> boxes. Checking the console revealed that we kept getting JS errors because target.currentDoc was undefined. I believe this should have been target.ownerDocument. I can confirm that this patch fixes the bug for me.
Attachment #8347447 - Flags: review?(jmathies)
Comment on attachment 8347447 [details] [diff] [review] Patch nice find!
Attachment #8347447 - Flags: review?(jmathies) → review+
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
Comment on attachment 8347447 [details] [diff] [review] Patch [Approval Request Comment] Bug caused by (feature/regressing bug #): Bug 898580 User impact if declined: Mouse clicks may be sent to unpredictable places on the page when a <select> box is scrolled and then clicked. This could result in incorrect items being selected in the list for example. Testing completed (on m-c, etc.): On m-c for a couple of days. Risk to taking this patch (and alternatives if risky): very low String or IDL/UUID changes made by this patch: none
Attachment #8347447 - Flags: approval-mozilla-aurora?
Attachment #8347447 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Verified as fixed for iteration #21, with latest Nightly and Aurora on Win 8 64-bit and 32-bit.
You need to log in before you can comment on or make changes to this bug.