Closed Bug 1178763 Opened 4 years ago Closed 3 months ago

TouchEvent.pageX/pageY should be undefined

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla69
Webcompat Priority P2
Tracking Status
firefox68 --- wontfix
firefox69 --- fixed

People

(Reporter: kats, Assigned: smaug)

References

()

Details

(Keywords: compat, dev-doc-complete, site-compat, Whiteboard: [webcompat][needs-wpt-?])

Attachments

(1 file)

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
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
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.
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.
(our current behaviour with TouchEvent, I mean)
Is there any update on this issue?
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.
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.
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?
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.
kats@ is correct. Chromium only exposes pageX/pageY on MouseEvent (and consequently PointerEvent) it does not expose it on UIEvent or TouchEvent.
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.
Why not use event.type.startsWith("touch") or check the prototype?
Priority: -- → P3
Flags: webcompat?
Whiteboard: [webcompat]

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

Webcompat Priority: --- → ?
Flags: webcompat?
Whiteboard: [webcompat] → [webcompat][needs-wpt-?]
Webcompat Priority: ? → P3

What spec should this live in?

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.

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

Webcompat Priority: P3 → P2
Assignee: nobody → bugs
Pushed by opettay@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/9005dd228db5
move UIEvent.pageX/pageY to MouseEvent, r=masayuki
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69

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.

You need to log in before you can comment on or make changes to this bug.