Open Bug 136407 Opened 23 years ago Updated 3 years ago

clientX and Y in drop-down SELECT list are wrong

Categories

(Core :: DOM: Events, defect, P5)

x86
Windows NT
defect

Tracking

()

People

(Reporter: Richard_Treitel, Unassigned)

References

Details

(Keywords: topembed-, Whiteboard: [DIGBug])

Attachments

(2 files)

819 bytes, application/octet-stream
Details
921 bytes, application/x-zip-compressed
Details
Mostly, see the test case that I'm about to attach (I hope). When I have a drop-down SELECT control opened and I click on an item, the resulting event has clientX and clientY relative to the top left corner of the list, not of the enclosing iframe nor the window (excuse me: the control is inside an iframe; I don't know what happens if it's inside a regular window). Reproducible in the build I got from ftp://ftp.mozilla.org/pub/mozilla/nightly/latest-0.9.9ec/ on 2nd April, a week ago today.
Attached file simple test case
Unzip, open bug.html in your browser, try some clicks in the left iframe, including some on the dropped-down list. You should see their clientX and clientY logged in the right iframe.
Bob, Kirk, this test case is an improvement on the one I mailed.
bryner knows all about this
Assignee: joki → bryner
I dont see a problem on build 2002-04-10-03-trunk on windows 98...
Still reproducible in ftp://ftp.mozilla.org/pub/mozilla/nightly/latest-1.0.0/embed-win32.zip size 4555816 bytes date 04/12/02 09:46:00
Keywords: nsbeta1+, topembed+
Whiteboard: [DIGBug]
Status: UNCONFIRMED → NEW
Ever confirmed: true
I don't think this is a bug per se. The DOM spec certainly doesn't indicate what should happen here; and it seems like any page which relies on clientX and clientY from a dropdown select is bound to run into problems -- there are no guarantees about the size or positioning of the popup. If we were using native widgets, it likely wouldn't be possible to even report clientX and clientY. I attempted to test IE's behavior in this case but the attached test case fails on IE 6.
just like my earlier test case (78365), but more flexible
As you will see from my new test case, IE does give the behaviour I wanted. (I tested in IE 5.5 bcos I don't have IE6). Moreover, at http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-MouseEvent-clientX we are told that clientX and clientY should be "relative to the DOM implementation's client area". I take the "client area" to mean the browser window ... at http://lists.w3.org/Archives/Public/www-svg/2002Jan/0018.html I find "DOM Implementation's client area (i.e. the user agent area used to display the whole DOM tree)".
Can you give me some idea what you're using this for? I'm having trouble envisioning a scenario where this couldn't be handled by "onchange" on the select element.
Target Milestone: --- → mozilla1.0
Richard, can you use the workaround Brian suggested?
Priority: -- → P5
Keywords: topembed+topembed-
nsbeta1- per workaround. -> mozilla1.2.
Status: NEW → ASSIGNED
Keywords: nsbeta1+nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.2beta
Hey , I'm a new member, I found this bug too with firefox 1.0.5 try this... <html> <head> <title></title> </head> <body> <form> <select style="position:absolute;left:100px;top:100px;"> <option>11111</option> <option>22222</option> <option>33333</option> <option>44444</option> <option>55555</option> </select> </form> <script> function showOffset(evt){ if(!evt){evt=window.event;} document.title=evt.clientY; } window.onmousemove= showOffset; </script> </body> </html> What happen when you click and move your mouse to select something...see the titlebar...Is this bug? and I think I found manny unusual things with firefox.
*** Bug 301433 has been marked as a duplicate of this bug. ***
Assignee: bryner → events
Status: ASSIGNED → NEW
QA Contact: vladimire → ian
Target Milestone: mozilla1.2beta → ---
When clicking a row of a tree that is placed within a menupopup, the wrong row will be selected. Is that related to this bug?
Assignee: events → nobody
QA Contact: ian → events
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: