944362 - Scrolling a <select> element causes mouse events on that element to have wrong y coordinates

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

Comment 1

[Jim Mathies [:jimm]]

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.

Comment 2

[Dmitrij D. Czarkoff]

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.

Comment 3

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

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.

Comment 4

[Dmitrij D. Czarkoff]

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

Comment 6

[Dmitrij D. Czarkoff]

Apparently I hit this bug with transmission webui too - scrolling list of torrents progressively offsets "y" coordinate of mouse clicks.

Comment 7

[Stephen A Pohl [:spohl]]

Attachment: Patch

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.

Comment 8

[Jim Mathies [:jimm]]

Comment on attachment 8347447 [details] [diff] [review]
Patch

nice find!

Comment 9

[Stephen A Pohl [:spohl]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/23abb5ffcfca

Comment 10

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/23abb5ffcfca

Comment 11

[Stephen A Pohl [:spohl]]

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

Comment 12

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/11d0763c3ca9

Comment 13

[Manuela Muntean [Away]]

Verified as fixed for iteration #21, with latest Nightly and Aurora on Win 8 64-bit and 32-bit.