Last Comment Bug 411031 - LayerX/Y properties are incorrectly calculated when a event is manually dispatched (initmouseevent)
: LayerX/Y properties are incorrectly calculated when a event is manually dispa...
Status: UNCONFIRMED
: testcase
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: 1.8 Branch
: x86 Windows XP
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Andrew Overholt [:overholt]
Mentors:
http://945.es/bugs/mozilla-firefox/in...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-06 11:10 PST by vituko
Modified: 2008-08-11 10:30 PDT (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase - pageX and layerX (3.57 KB, text/html)
2008-03-22 00:13 PDT, Garrett Smith
no flags Details
automatable pageY testcase (1.80 KB, text/html)
2008-07-07 12:20 PDT, Dan Fabulich
no flags Details

Description vituko 2008-01-06 11:10:14 PST
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 2008-03-22 00:13:32 PDT
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: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 2008-07-04 09:48:30 PDT
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 2008-07-04 11:10:13 PDT
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 2008-07-07 12:20:28 PDT
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 5 Olli Pettay [:smaug] 2008-07-07 12:40:22 PDT
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 2008-07-07 12:52:27 PDT
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 sstchur@microsoft.com is a MS Virtual Earth maps developer.)

Should I file a separate bug for this pageY behavior?
Comment 7 Dan Fabulich 2008-07-07 14:04:07 PDT
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 2008-07-08 00:46:39 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.