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

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Dan Fabulich]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

PageX/Y represent the horizontal/vertical coordinates of an event relative to the whole document.  This differs from clientX/clientY, which are the horizontal/vertical coordinate within the application's client area.  When you scroll a document and then fire an event, the pageY should be the clientY + scrolldata.

This works as expected in FF2, and it works in FF3 when clicking manually.  But when manually dispatching events, in FF2 pageY would include scrolldata; in FF3 pageY does not include scrolldata but ONLY when manually dispatching.

Reproducible: Always

Steps to Reproduce:
Open the attached page in FF3.  This page includes a 4000px spacer div, followed by two buttons: "report pageY" and "Simulate mouseup on the other button".  During onload, a mouseup is automatically simulated.
Actual Results:  
You'll see the word "FAIL" in the body of the page, because pageY is less than 4000.  If you manually click on "report pageY" you'll see the word "PASS" in the body of the page.  You may also manually click on the "simulate mouseup" button to get the word "FAIL" to appear again.  On my machine, pageY is typically ~1000px.

Expected Results:  
The word "PASS" should appear in the body of the page, regardless of whether you push the left button or the right button.  pageY should always be >4000.

This bug was discussed elsewhere in bug 411031 and bug 405632. This regression  caused a bug in Microsoft's Virtual Earth maps, which depended on the behavior of pageY.

There is no public standard for the behavior of pageY, but there is a defacto standard behavior: FF2, Safari 3.1 and Opera 9.5 all behave the same way (they all say "PASS" when you load up the page).  FF3 changed the behavior of this attribute incorrectly.

Comment 1

[Dan Fabulich]

Attachment: test case

Comment 2

[Stephen Stchur]

In bug 411031, I see that some were saying this is really a feature, and not a bug.

I'm not sure what the intended design was, but this is definitely different behavior from what FF2 and most other W3C browsers exhibit.

Furthermore, it seems reasonably to me that the pageX/Y properties of a mouse event ought to return the "page" position of that event (i.e. where the mouse cursor was at the time the event occurred).

Its very name implies that it would return the position relative to the page (thus accounting for scroll position).  And I'd expect this to be the case, regardless of whether or not the event was manually dispatched.

Why even make a distinction between clientX/Y and pageX/Y in the first place?  Common convention has it that clientX/Y return the coordinates relative to the upper right corner of the browser window's viewport, while pageX/Y return the coordinates relative to the upper right corner of the HTML page.

It doesn't make sense that pageX/Y would behave differently between a naturally occurring event and one that was manually dispatched, because changing the behavior of pageX/Y to return something OTHER than the "page" position destroys the accuracy of the (otherwise) semantically correct property name.

Comment 3

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

I guess I could bring back the FF2 behavior, although the behavior with
non-visual documents is unclear.
(What really should be done is to extends initMouseEvent method or add a new
similar method for pageX/Y and layerX/Y - but only if such method is defined in
some specification.)

(In reply to comment #2)
> most other W3C browsers exhibit.
pageX/Y isn't really a feature specified by W3C .

> ... (i.e. where the mouse cursor was at the time the event occurred).
Right. When dispatching an event manually, the cursor isn't necessarily over the
browser at all ;)

But anyway, because of backward compatibility I think the old behavior could
be brought back. I'll write the patch tomorrow.

Comment 4

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

Btw, this is a regression from bug 370492.

Comment 5

[Garrett Smith]

I first found that the pageX/Y properties did not work under FF2; was always 0. 

Stephen provided a patch along the lines of:-
MouseEvent.prototype.__defineGetter__('pageX', function() {
        return this.clientX + window.pageXOffset;
});
MouseEvent.prototype.__defineGetter__('pageY', function() {
        return this.clientY + window.pageYOffset;
});

comment #2 Only one person thought this was a feature. Apparently, and even after all of the well-reasoned argument and example-based discussion, he still does.

Comment #3 - it's not really necessary to restate that there isn't a w3c recommended feature; that's in the Description. This doesn't really have to do with backward compatibility; though the historical implementation of pageX property has lead to its widespread use (which you seem to be unaware of). As 

Dan pointed out, this bug is very serious for automated web test frameworks. Selenium is one such framework. YUI Test is another framework that creates events. (Unfortunately Nicholas (YUI Test author) decided to mark the bug INVALID rather than investing the energy and effort into addressing bugs related to his software.)

http://sourceforge.net/tracker/index.php?func=detail&aid=1922892&group_id=165715&atid=836476

The bug is that pageX is broken. That's the part that has been explained to you, but maybe now that there is a new title for the bug, 

Comment 6

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

Attachment: old pageXY + tests

Comment 7

[Johnny Stenback (:jst)]

Not marking this wanted, but feel free to land and/or nominate patches once they're ready.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think we should take this on the 3.0.x branch too.

Comment 9

[Daniel Veditz [:dveditz]]

we're using wanted-minus on branch to mean "we want it NOT to go on branch" and simply clearing it if we'd consider a patch later. I think the latter is what comment 7 was about.

Comment 10

[Daniel Veditz [:dveditz]]

Comment on attachment 328465 [details] [diff] [review]
old pageXY +  tests

Not clear why this needs to go into a branch release, and the QA load is getting too high for 3.0.4 as it is.

Comment 11

[Dan Fabulich]

(In reply to comment #10)
> (From update of attachment 328465 [details] [diff] [review])
> Not clear why this needs to go into a branch release, and the QA load is
> getting too high for 3.0.4 as it is.

Well, it might have been wise to put it in a branch because it's a regression from FF2 that causes a breakage in any site that embeds Microsoft Virtual Earth maps.  But most such sites now workaround this bug with user agent sniffing.  

Sniffing works just fine; any fix in the branch would probably break the workaround, right?

... and we all love user agent sniffing, right? :-(

Comment 12

[Daniel Veditz [:dveditz]]

Yes, fixing it in 3.0 would have been better, and it's good that it's getting fixed in 3.1 (go play with the beta). Beyond that, is the gain of fixing it now in a 3.0.x worth the QA cost, regression risk, and potentially breaking sites that _have_ worked around it? Are we helping millions of users on thousands of sites, or just a few dozen users? We don't really know, but this particular issue has not come up as a support issue.