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.