1178763 - TouchEvent.pageX/pageY should be undefined

Status: RESOLVED FIXED

(Core :: DOM: Events, defect, P3)

Description

[Kartikaya Gupta (email:[e-mail])]

Currently the pageX and pageY properties on TouchEvent (*not* the touch objects, but the top-level event itself) seem to return the scroll position. According to the discussion on input-dev [1] these properties should be undefined.

[1] https://groups.google.com/a/chromium.org/d/msg/input-dev/4p1XZy_17aw/qi-LQuOtvpcJ

Comment 1

[dtapuska]

In FireFox:
UIEvent.prototype.hasOwnProperty('pageX')
true
MouseEvent.prototype.hasOwnProperty('pageX')
false

Chromium is going to try to invert them; see:
https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/pageX/blink-dev/pcMwyHRhbCU/FiVwBbImrS0J

Comment 2

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

It would be a tad risky change to move pageX/Y from UIEvent to MouseEvent, given that the properties
have been in UIEvent for 10+ years.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

We can wait for Blink to do it and see if they run into compat problems. If they don't then we should be ok to make the change as well. It would be good to standardize on something consistent, and our current behaviour is clearly just wrong.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

(our current behaviour with TouchEvent, I mean)

Comment 5

[Kartikaya Gupta (email:[e-mail])]

This landed in Blink.

Comment 6

[fanshine]

Is there any update on this issue?

Comment 7

[RedRed77]

Hello, 
Would you please clarify the status of this issue cause, as I can see, all other browsers fixed this issues years ago?
Hope to hear from you soon.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

Are you running into specific issues because of this? As far as I call tell you should be able to easily work around the current behaviour if it's causing problems - please let us know if that's not the case.

Comment 9

[fanshine]

We check pageX/pageY to determine if the page is opened on the touch-enabled device\monitor because we have a different implementation for drag, drop, click (tap) events for touch and non-touch devices\monitors. What workaround do you mean?

Comment 10

[Kartikaya Gupta (email:[e-mail])]

As I understand it, the pageX/pageY properties shouldn't even exist on TouchEvent. So if you're reading those properties and getting bad values, you should just not read those properties and use something else. You'll have to do that anyway once this bug is fixed so you might as well start doing that now.

Comment 11

[dtapuska]

kats@ is correct. Chromium only exposes pageX/pageY on MouseEvent (and consequently PointerEvent) it does not expose it on UIEvent or TouchEvent.

Comment 12

[fanshine]

The problem is that pageX/pageY in all browsers are undefined. But in the firefox, pageX/pageY properties contain values. So it is not possible to understand what event raise - touch or mouse.

Comment 13

[dtapuska]

Why not use event.type.startsWith("touch") or check the prototype?

Comment 14

[Karl Dubost💡 :karlcow]

Context for https://webcompat.com/issues/15381

It basically breaks this code by giving a whacky computation for the Justapoxe library used for creating sliders with two images Before/After.
https://github.com/NUKnightLab/juxtapose/blob/c4ec3e076319366bdf8b69647cd5855d25bbb772/juxtapose/js/juxtapose.js#L173-L183

  function getPageX(e) {
    var pageX;
    if (e.pageX) {
      pageX = e.pageX;
    } else if (e.touches) {
      pageX = e.touches[0].pageX;
    } else {
      pageX = e.clientX + document.body.scrollLeft + document.documentElement.scrollLeft;
    }
    return pageX;
  }

e.pageX gives a very different result than e.touches[0].pageX

Comment 15

[Mike Taylor [:miketaylr]]

What spec should this live in?

Comment 16

[Kartikaya Gupta (email:[e-mail])]

It's already really part of the TouchEvents spec, in that there's no pageX/pageY defined on TouchEvent in the spec. Our implementation is just wrong.

Comment 17

[Mike Taylor [:miketaylr]]

Ah, I see. Thanks for clearing that up for me.

Comment 18

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

Attachment: Bug 1178763, move UIEvent.pageX/pageY to MouseEvent, r=masayuki

Comment 19

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

https://treeherder.mozilla.org/#/jobs?repo=try&revision=4c33521590de3d888b245a1a3fdf6de24153c6b1

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9005dd228db5
move UIEvent.pageX/pageY to MouseEvent, r=masayuki

Comment 21

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/9005dd228db5

Comment 22

[Kohei]

Posted site compatibility note: https://www.fxsitecompat.dev/en-CA/docs/2019/pagex-pagey-have-been-moved-from-uievent-to-mouseevent/

Comment 23

[Chris Mills [:cmills]]

I've added a rel note to the Fx 69 rel notes about this:

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/69#APIs

(Some wording stolen from Kohei's compat post, as it was awesome!)

I don't think aanything else is needed here. MDN already lists these properties on MouseEvent and UIEvent, but the on the latter they are listed as non-standard/do not use. And the compat data looks reasonable.