LayerX/Y properties are incorrectly calculated when a event is manually dispatched (initmouseevent)




DOM: Events
10 years ago
9 years ago


(Reporter: vituko, Unassigned)



1.8 Branch
Windows XP

Firefox Tracking Flags

(Not tracked)




(2 attachments)



10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv: Gecko/20071127 Firefox/
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv: Gecko/20071127 Firefox/

LayerX/Y properties are incorrectly calculated when a event is manually dispatched (initmouseevent)
This error happens only in gecko, not in khtml/safari, see the example.
It's very simple, compare the example in Firefox and then in Safari / Konqueror.

Reproducible: Always

Steps to Reproduce:


10 years ago
Component: Build Config → DOM: Events
Product: Firefox → Core
Version: unspecified → 1.8 Branch
QA Contact: build.config → events

Comment 1

10 years ago
Created attachment 311116 [details]
testcase - pageX and layerX 

This bug also affects pageX and pageY.

However, I cannot say that the Webkit gets the right result. 

The dispatched event has:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080201 Firefox/
e.layerX (0)
e.layerY (0)

e.pageX (1) == PAGE_X (9):   false
e.pageY (1) == PAGE_Y (9):   false

Webkit 5.23.15 (Safari/windows):
e.layerX (-7)
e.layerY (-7)

e.pageX (1) == PAGE_X (9):   false
e.pageY (1) == PAGE_Y (9):   false


These results are not right. Instead, the dispatched event should have:
e.layerX (1)
e.layerY (1)

e.pageX (9) == PAGE_X (9):   true
e.pageY (9) == PAGE_Y (9):   true

Other observation:
Firefox sets the values from 'human' created coords starting with {1, 1}. Webkit sets the event's values from coords {0, 0}.


10 years ago
Keywords: testcase

Comment 2

9 years ago
I have written a blog post which examines the details of this bug, and what a possible (javascript-based) work-around is.

Please see:

Comment 3

9 years ago
Can we use something based on that patch?

MouseEvent.prototype.__defineGetter__('pageX', function() {
	return this.clientX + window.pageXOffset;
MouseEvent.prototype.__defineGetter__('pageY', function() {
	return this.clientY + window.pageYOffset;

This bug appears in Firefox 2 on windows (as stated)
Not in Flock on Mac, using rv:

Not in FF3 on Mac. 
e.pageX (8) == PAGE_X (9):   false

(this seems to be what should really be the expected result (testcase needs update))

Comment 4

9 years ago
Created attachment 328366 [details]
automatable pageY testcase

I've submitted a simpler test case for this bug that highlights the problem with pageY.  This test case is suitable for automation.

The attached test case has a spacer div 4000px tall and two buttons: "report pageY" and "Simulate mouseup on the other button".  If you manually click on the "report pageY" button, it will report a number >4000, as expected.  But if you click on the "simulate" button, it will report a number smaller than 4000, which is a bug.

During onload the test automatically scrolls the buttons into view and performs a simulated click; a valid layout test should assert that the word "PASS" appears in the output and that the word "FAIL" doesn't appear.

I ran the test myself.  Contra Garrett's findings, I find that this test fails on FF3 on Windows/Mac and passes on FF2 on Windows/Mac.  It passes on Safari 3.1 on Windows/Mac and on Opera 9.5 Windows/Mac.

As Stephen points out in his blog post, this bug creates a regression on Microsoft Virtual Earth maps on pages that require scrolling; you can't drag the map to pan.

This bug is very serious for automated web test frameworks like Selenium, which operate by simulating mouse events to simulate user actions.  Code that relies on pageX/pageY will appear to work manually but will fail under automated tests.
Comment on attachment 328366 [details]
automatable pageY testcase

At least based on the summary this bug is about layerX/Y and this testcase tests only pageX/Y (which are initialized to clientX/Y when event is dispatched manually, see Bug 405632).

Comment 6

9 years ago
Bug 405632 is certainly relevant!  Alarmingly, it is supposedly resolved/fixed, but the latest Minefield nightly still fails my attached automatable pageY test.  (I believe is a MS Virtual Earth maps developer.)

Should I file a separate bug for this pageY behavior?

Comment 7

9 years ago
In bug 405632 comment #23, Smaug suggested I file a separate bug for pageX/pageY.  I've filed a separate bug 443985.

Comment 8

9 years ago
Did you see my original example????
Slimply compare with Safari.

In firefox3 (WinXP, I'm still working with iceweasel 2 in linux) the behavior changed but it's still boggus and maybe worst.
In my example, layerX/Y are now always 0, before (branch 2) it was boggus but "proportional" (red box: 1-200 -> 67-83), like scaled, do you follow me? Excuse my english.
You need to log in before you can comment on or make changes to this bug.