329938 - Mouse Position Wrong over <select> Popup

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[memso]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

I spent half an hour trying to see if this bug was listed already, so I'm sorry if this is a repeat.
The OS I am using is Windows XP x64, but that doesn't seem to make a difference. I've also had this occur in Firefox 1.0.7 in Windows XP SP2

Exact Problem:
The mouse position is reported incorrectly when moving over the Popup that appears from a <select>, as if the coordinates of the popup start at 0,0.


Reproducible: Always

Steps to Reproduce:
1. Head to http://www.golflocker.com/jspositionbug.html, or any site that has something that follows the mouse everywhere and has <select> drop down
2. Click on the <select>
3. Mouse over the popup.

Actual Results:  
The mouse position for e.clientX/Y and e.pageX/Y both report the X and Y position relative to the upper left corner of the <select> popup instead of the document window.

Expected Results:  
The mouse position should continue reporting the X/Y positions relative to the browser window instead of the popup window

Comment 1

[Polly]

I see the same behaviour with Seamonkey on eMac running 10.2.8.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060215 SeaMonkey/1.5a 

If the mouse is in the drop-down list, the popup should disappear, in my opinion. You need the position relative to the drop-down so you can choose one of the options. But don't mind me, I have no idea what I'm talking about really, I'm just reporting that it does the same thing in SeaMonkey.

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.0.1)
> Gecko/20060111 Firefox/1.5.0.1
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.0.1)
> Gecko/20060111 Firefox/1.5.0.1
> 
> The OS I am using is Windows XP x64, but that doesn't seem to make a
> difference. I've also had this occur in Firefox 1.0.7 in Windows XP SP2
> 
> Exact Problem:
> The mouse position is reported incorrectly when moving over the Popup that
> appears from a <select>, as if the coordinates of the popup start at 0,0.
> 

Comment 2

[Martijn Wargers (dead)]

Confirmed, with current trunk build. Reporter, could you attach the testcase to the bug? Thanks.

Comment 3

[Martijn Wargers (dead)]

Maybe Event Handling is a more correct component.

Comment 4

[memso]

http://www.golflocker.com/items.asp?deptid=4&itemid=2

This is the real page I noticed the problem on. Wait until the page loads, and the realZOOM component fires up. If you mouse over the image, it shows a nice zoomed in version of the main product.

However, if I choose the "first, select size" drop down (move the page down a bit with the scrollbar first) and move to the bottom right of the popup that appears, I can cause the mouse position to interfere with the zoom component and it thinks we're over the image, improperly showing the zoom region. What's interesting is that the Y position is affected by the scrollbar of the main page, so if you don't move the scroll bar down a little before mousing over the <select>'s drop down, the problem does not appear.

It is really pronounced if you make the drop down appear near the top of the page, then almost the whole right edge of the <select> drop down causes the zoom popup.

Because this page is centered, if you have your browser really wide (more than 900), you won't notice the problem since the X coordinates will be rather low. If the browser window is around 800 wide, almost the entire <select> drop down spawns the zoom.

Hope any of this is helpful...

Comment 5

[memso]

Attachment: Simple HTML that shows the problem

This is the source for the sample

Comment 6

[Martijn Wargers (dead)]

*** Bug 332729 has been marked as a duplicate of this bug. ***

Comment 7

[memso]

Running through my FF bugs list, I found that in FF 2.0.0.2 the bug still occurs. In Minefield 3.0a3pre (Nightly Build for 03-09-2007), however, e.pageX and e.pageY are correct in the test case, though e.clientX and e.clientY are not. Is this a "design" decision, and in reality it's fixed?

Comment 8

[Martijn Wargers (dead)]

No, it's not a design decision.
e.pageX/e.pageY was fixed with the testcase between 2007-02-17 and 2007-02-18, fixed by bug 370492, I think.
I guess a similar treatment is necessary for the clientX and clientY properties, right, Eli?

Comment 9

[Eli Friedman]

Sure, eventually.  Depends on the popup rewrite because popups use clientX/Y at the moment.

Comment 10

[Martijn Wargers (dead)]

Ok, this is now worksforme, using current trunk build.