Bug Tracker

Opened 7 years ago

Closed 7 years ago

Last modified 6 years ago

#12343 closed bug (cantfix)

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

Reported by: anonymous Owned by: anonymous
Priority: undecided Milestone: None
Component: event Version: 1.8.0
Keywords: Cc: dmethvin
Blocked by: Blocking:

Description

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.

Change History (22)

comment:1 Changed 7 years ago by timmywil

Owner: set to anonymous
Status: newpending

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.

comment:2 Changed 7 years ago by trac-o-bot

Resolution: invalid
Status: pendingclosed

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!

comment:3 Changed 7 years ago by anonymous

comment:4 Changed 7 years ago by mikesherov

Component: unfiledevent
Resolution: invalid
Status: closedreopened

comment:5 Changed 7 years ago by mikesherov

Cc: dmethvin added

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

comment:6 Changed 7 years ago by dmethvin

Status: reopenedpending

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?

comment:7 Changed 7 years ago by 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

comment:8 Changed 7 years ago by dmethvin

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

comment:9 Changed 7 years ago by anonymous

Status: pendingnew

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.

comment:10 Changed 7 years ago by anonymous

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

comment:11 Changed 7 years ago by 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.

comment:12 Changed 7 years ago by dmethvin

Status: newopen

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.

comment:13 Changed 7 years ago by 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

comment:14 Changed 7 years ago by dmethvin

Resolution: cantfix
Status: openclosed

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.

comment:15 Changed 7 years ago by dmethvin

#12598 is a duplicate of this ticket.

comment:16 Changed 6 years ago by stephen

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

comment:17 in reply to:  16 ; Changed 6 years ago by 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.

comment:18 in reply to:  17 Changed 6 years ago by 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.

comment:19 Changed 6 years ago by anonymous

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

comment:20 Changed 6 years ago by 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.

comment:21 Changed 6 years ago by 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.

comment:22 Changed 6 years ago by 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.

Note: See TracTickets for help on using tickets.