event.pageX and pageY have incorrect values in IE10 on Windows 8 RTM

[anonymous]

NOTE: tested using jQuery 1.7.2 and 1.8.0, both have this problem. Test was done using a HTML5 doctype, didn't test older doctypes.

In Internet Explorer 10 that came with Windows 8 RTM, event.pageX and event.pageY both have incorrect values:

Instead of returning the mouse position relative to the document's Left/Top, the values returned are relative to the IE10 viewport's Left/Top.

To reproduce this problem, simply scroll a page half way to the right and half way down, move mouse around and you can see the incorrect values returned.

[Timmy Willison]

Thanks for taking time to contribute to the jquery project! Please help us assess your ticket by providing a test case from  ​http://jsfiddle.net or  ​http://jsbin.com using the git version of jQuery.

[trac-o-bot]

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!

[anonymous]

test case on jsfiddle: ​http://jsfiddle.net/LbKfR/1/

test case on jsbin: ​http://jsbin.com/ozicok/1/ Code view: ​http://jsbin.com/ozicok/1/edit

[mikesherov]

I'm unable to reproduce this issue on IE10 on browserstack. dmethvin, any luck?

[dmethvin]

I cannot reproduce this either. If I move the x/y scroll bars to the center of their range and click in the top left of the visible blue area, I get a suitably large x/y value as I would expect. On my Samsung tablet, it works in desktop IE10 with both a real mouse and with the simulated mouse events generated by a touch event. In the Metroish IE10, it works properly with touch events as well, although scrolling is a bit tricky.

Is it possible that some browser plugin is interfering? What's different about your setup?

[mplank@…]

​http://simonsarris.com/blog/510-making-html5-canvas-useful first not scroll and drag, then scroll and drag <- not work / Test IE10 an Windows 8 RTM

[dmethvin]

Please reduce this to a simpler test case. There's a lot of stuff on that page.

[anonymous]

This bug was discovered using Windows 8 Ultimate RTM (from MSDN) installed in Oracle VirtualBox. It can be reproduced in both the Metro IE10 and the ordinary IE10.

[anonymous]

Typo above: it's Windows 8 Enterprise RTM (from MSDN) in Oracle VirtualBox, there's no Ultimate edition of Windows 8.

[anonymous]

The setup above (Win8 Enterprise RTM on Oracle VirtualBox) was completely clean, clean windows install and nothing else, didn't even change any IE settings from default.

Just tested using Windows 8 RC but it doesn't have this problem, so I guess only the RTM.

[dmethvin]

Okay, I finally did get this to repro. I had tried it on my Lenovo notebook before and it didn't seem to occur, but this time it did. Here is a screen shot of the problem clipped from the jsFiddle case. I set the scroll bars to the center and clicked on the upper left hand corner of the window (the blue area). It should have returned document-relative coordinates but instead it returned window-relative coordinates: ​http://i.imgur.com/Ct6W8.png

Browserstack and my Samsung tablet are still on the older pre-release version; neither have the issue: ​http://i.imgur.com/AOrG2.png

As for a solution, I am not sure one is possible at the jQuery level without browser sniffing. I'll contact Microsoft and see if they can give us some more info. Leaving open for now.

[dmethvin]

Corrected fiddle, still showing error (the other one had bad markup but it didn't affect the problem): ​http://jsfiddle.net/LbKfR/3/show

[dmethvin]

I heard back from Microsoft, they have a patch that will go out a few days after the official public release that will fix this issue. There's no reliable marker that jQuery can use to tell fixed vs unfixed implementations, so your best bet is to tough it out until then.

[dmethvin]

#12598 is a duplicate of this ticket.

[stephen]

This seems to have been fixed by a recent update of IE10.

[anonymous]

Replying to stephen:

This seems to have been fixed by a recent update of IE10.

Could you provide fix version number of IE10. I can't find anything from MSDN.

[anonymous]

For clarity this issue is now fixed in IE build 10.0.9200.16484

The IE10 Win8 RTM was 10.0.9200.16384

IE updates were KB2792100 & KB2797052, I am not shore which one fixed it.

[anonymous]

It's still present in the current IE10 version when first installed... Any ideas...?

[dmethvin]

Run Windows Update? In any case Microsoft does have a fix and we can't apply one anyway. If you can't solve the problem please ask for help on a forum.

[peter.mescalchin@…]

Would just like to add for the record, I was able to reproduce and confirm this behaviour with my own JavaScript library/code. Ended up here on a Google search - thought I would add my notes.

With IE10 10.0.9200.16384 (bundled with the Win8/IE10 VM images at ​http://modern.ie/ as of March 2013 - may now be updated) e.pageX/e.pageY is mis-reported, behaving like e.clientX/e.clientY of classic IE version 6/7/8.

Performing a Windows update to now 10.0.9200.16580 the behaviour has now corrected itself, e.pageX/e.pageY now report as expected.

[rwwl]

Weird, I updated to 10.0.9200.16580 on my IE10 Windows 8 VM (the one supplied at modern.ie) and I still see this issue.