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

Status: UNCONFIRMED

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

Description

[vituko]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

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:
1.
2.
3.

Comment 1

[Garrett Smith]

Attachment: 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:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
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}.

Comment 2

[Stephen Stchur]

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

Please see: http://blog.stchur.com/2008/07/03/firefox-3-pagex-pagey-bug/

Comment 3

[Garrett Smith]

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:1.8.1.11

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

[Dan Fabulich]

Attachment: 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 5

[Olli Pettay [:smaug][[e-mail]]]

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

[Dan Fabulich]

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 [e-mail] is a MS Virtual Earth maps developer.)

Should I file a separate bug for this pageY behavior?

Comment 7

[Dan Fabulich]

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

Comment 8

[vituko]

Did you see my original example????
http://945.es/bugs/mozilla-firefox/initmouseevent_layerXY.html
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.

Comment 9

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.