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)
Tracking
()
NEW
People
(Reporter: Richard_Treitel, Unassigned)
References
Details
(Keywords: topembed-, Whiteboard: [DIGBug])
Attachments
(2 files)
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.
Reporter | ||
Comment 1•23 years ago
|
||
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.
Reporter | ||
Comment 2•23 years ago
|
||
Bob, Kirk, this test case is an improvement on the one I mailed.
Comment 4•23 years ago
|
||
I dont see a problem on build 2002-04-10-03-trunk on windows 98...
Reporter | ||
Comment 5•23 years ago
|
||
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
Updated•23 years ago
|
Updated•23 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 6•23 years ago
|
||
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.
Reporter | ||
Comment 7•23 years ago
|
||
just like my earlier test case (78365), but more flexible
Reporter | ||
Comment 8•23 years ago
|
||
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)".
Comment 9•23 years ago
|
||
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.
Updated•23 years ago
|
Target Milestone: --- → mozilla1.0
Updated•23 years ago
|
Comment 11•23 years ago
|
||
nsbeta1- per workaround. -> mozilla1.2.
Comment 12•20 years ago
|
||
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.
Comment 13•20 years ago
|
||
*** Bug 301433 has been marked as a duplicate of this bug. ***
Updated•19 years ago
|
Assignee: bryner → events
Status: ASSIGNED → NEW
QA Contact: vladimire → ian
Target Milestone: mozilla1.2beta → ---
Comment 14•18 years ago
|
||
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?
Updated•16 years ago
|
Assignee: events → nobody
QA Contact: ian → events
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•