MouseEvent.pageX/pageY fill isn't needed in jQuery 3.0

[anseki]

Related to: #3080
Original comment: #3080 (comment)

MouseEvent.pageX/pageY also might be influenced.

jquery/src/event.js

Line 435 in 9f268ca

( doc && doc.clientLeft || body && body.clientLeft || 0 );

If native event don't have pageX/Y, these are calculated using clientLeft/clientTop.

If html element has border-width:10px like the example above, in a browser that doesn't support event.pageX/Y and correct clientTop/clientLeft, jQuery returns 10,10 as pageX/Y, when mouse is positioned at left-top-corner of body. In a browser that returns correct clientTop/clientLeft, jQuery returns 0,0 as pageX/Y.

I feel that 10,10 is correct result.

But I don't know recent browser that doesn't support event.pageX/Y.

Since Firefox returns 0 as clientTop/clientLeft of html element always, MouseEvent.pageX/pageY might be incorrect.
When native event object doesn't have pageX/Y, jQuery.event.mouseHooks.filter calculates these using document.documentElement.clientLeft/clientTop (i.e. border-width of html element).
(But I don't know recent browser that doesn't support event.pageX/Y.)

Represent:
https://jsfiddle.net/rent9q5g/
This simulates a browser that doesn't support event.pageX/Y.

Chrome:

IE:

Firefox:

incorrect result in Firefox by its bug, but I think pageX: 10 pageY: 10 is correct result. That is, jQuery.event.mouseHooks.filter should not subtract clientTop/clientLeft.

[dmethvin]

It's possible we don't need that code at all in 3.x (maybe even 2.x) depending on where pageX/Y are provided. If https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/pageX is correct it seems we should be covered even for 2.x. Removing it would be better than fixing it!

[gibson042]

Removing it would be better than fixing it!

Agreed.

[dmethvin]

I think we should remove the pageX/Y fill in 3.0, it seems to have full browser support. Let's discuss on Monday, I won't submit a PR now because it will conflict with @jbedard 's PR and we might as well create one on top of that.

[dmethvin]

Hey @anseki I just wanted to confirm that this problem does not exist in any of the event.pageX values that the browser calculates, correct? Once we remove our calculation as proposed in gh-3106 there should be no problem. (Unless the browser doesn't support event.pageX!)

[anseki]

I think that pageX/pageY of native event object are correct.
I updated the code above in JSFiddle.
https://jsfiddle.net/rent9q5g/2/
At least, Native pageX/pageY seem correct in current Firefox, Chrome and IE.

[dmethvin]

Awesome, thanks for the confirmation!