283996 - Invalid clientX and clientY

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Micha Schopman]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Build Identifier: FireFox 1.0 and FireFox 1.01

When dragging an element from frame 1 to frame 2, the second frame returns 
wrong clientX and clientY variables. They appear to be switched with screenX 
and screenY.

Testcase has been created by Crisp.

Reproducible: Always

Steps to Reproduce:
1. mousedown on green box
2. drag box to 2nd frame
3. 2nd frame handles coordinates but returns wrong coordinates

A normal mousemove without dragging returns normal coordinates

Actual Results:  
Coordinates are calculated based on the top left screen area.

Expected Results:  
Coordinates should be calculated based on the top left iframe area.

Comment 1

[crisp]

Simpler testcase: http://allcrispy.com/meuk/dragbug.html

When you enter the iframe say from the top-left side the onmouseover event in
the iframe will show pageX/clientX and pageY/clientY starting at 0,0
Now when you hold down your left mousebutton in the main document and drag into
the iframe from the top-left side pageX/clientX and pageY/clientY will start at
302,302 which is actually the mouse position in the main document returned from
the event in the iframe.

Comment 2

[Martijn Kint]

Confirmed for FF 1.0.1 OS X

Comment 3

[José Jeria]

This works as expected using trunk build 20050228 on windows xp. Was able to
reproduce with 1.0, so this has been fixed.

Please reopen if you can reproduce with a trunk build.

Comment 4

[Miska Natunen]

I was able to reproduce the bug with Firefox 1.0.4 (Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4), using the
testcase by Crisp, so this should be reopened.

The bug also occurred on a page with three iframes, but only with one of the
iframes - on the other two clientX and clientY were returned correctly. Other
onmousemove event properties (such as the view property) seemed to be correct
with each iframe.

Comment 5

[José Jeria]

(In reply to comment #4)
> I was able to reproduce the bug with Firefox 1.0.4 (Mozilla/5.0 (Windows; U;
> Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4), using the
> testcase by Crisp, so this should be reopened.

No, see comment 3 please. Only reopen if you can reproduce with a trunk build