TouchEvent.pageX/pageY should be undefined
Categories
(Core :: DOM: Events, defect, P3)
Tracking
()
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
|
Reporter | |
Updated•8 years ago
|
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
|
Assignee | |
Comment 2•8 years ago
|
||
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.
|
|
Reporter | |
Comment 3•8 years ago
|
||
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.
|
|
Reporter | |
Comment 4•8 years ago
|
||
(our current behaviour with TouchEvent, I mean)
|
|
Reporter | |
Comment 5•8 years ago
|
||
This landed in Blink.
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.
|
|
Reporter | |
Comment 8•6 years ago
|
||
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?
|
|
Reporter | |
Comment 10•6 years ago
|
||
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•6 years ago
|
||
kats@ is correct. Chromium only exposes pageX/pageY on MouseEvent (and consequently PointerEvent) it does not expose it on UIEvent or TouchEvent.
|
||
Comment 12•6 years ago
|
||
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•6 years ago
|
||
Why not use event.type.startsWith("touch") or check the prototype?
|
||
Updated•5 years ago
|
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
|
||
Comment 14•5 years ago
|
||
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
|
||
Updated•5 years ago
|
|
||
Updated•4 years ago
|
|
|
||
Updated•4 years ago
|
|
||
Updated•4 years ago
|
|
|
||
Updated•4 years ago
|
|
|
||
Updated•4 years ago
|
|
|
||
Comment 15•4 years ago
|
||
What spec should this live in?
|
|
Reporter | |
Comment 16•4 years ago
|
||
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•4 years ago
|
||
Ah, I see. Thanks for clearing that up for me.
|
|
||
Updated•4 years ago
|
|
|
Assignee | |
Updated•4 years ago
|
|
|
Assignee | |
Comment 18•4 years ago
|
||
|
|
Assignee | |
Comment 19•4 years ago
|
||
|
||
Comment 20•4 years ago
|
||
Pushed by opettay@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/9005dd228db5 move UIEvent.pageX/pageY to MouseEvent, r=masayuki
|
||
Comment 21•4 years ago
|
||
| bugherder | ||
|
||
Updated•4 years ago
|
|
|
||
Comment 22•4 years ago
|
||
Posted site compatibility note: https://www.fxsitecompat.dev/en-CA/docs/2019/pagex-pagey-have-been-moved-from-uievent-to-mouseevent/
|
||
Comment 23•4 years ago
|
||
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.
Description
•