WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
181954
TouchMove event contains incorrect clientX / clientY after window scroll
https://bugs.webkit.org/show_bug.cgi?id=181954
Summary
TouchMove event contains incorrect clientX / clientY after window scroll
alexreardon
Reported
2018-01-22 14:36:32 PST
Created
attachment 331965
[details]
Logs After a window scroll, the first subsequent touch move event has incorrect clientX / clientY values. This is fixed on the next touchmove event. This occurs frequently, but not every time. It looks like around 10% of the time.
Attachments
Logs
(308.32 KB, image/png)
2018-01-22 14:36 PST
,
alexreardon
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
alexreardon
Comment 1
2018-01-22 14:38:11 PST
This seems related to
https://bugs.webkit.org/show_bug.cgi?id=32899
but it might be a seperate issue. I can confirm the issue still occurs: - when the events are bound in different orders - regardless of whether it is bound in the capture phase - regardless of whether the touchmove handler is passive or not
alexreardon
Comment 2
2018-01-22 15:57:56 PST
It looks like multiple post scroll touchmove events can contain incorrect values
Simon Fraser (smfr)
Comment 3
2018-01-22 17:24:26 PST
Can you make a small test case?
alexreardon
Comment 4
2018-01-22 18:46:51 PST
I have put one together:
https://codepen.io/alexreardon/pen/BJEaRL?editors=1111
It is fairly crude but shows the issue. Press on the drag handle and move it around. You will see that it goes up on the page on Safari + iOS11 because the clientY is getting smaller after each scroll - it is being incorrectly impacted by the window scroll. The drag handle stays in the same place in other browsers which have the correct clientX / clientY after a scroll.
alexreardon
Comment 5
2018-01-22 19:27:55 PST
I have tested it on latest Chrome on Android and the drag handle stays in the same place (the clientX and clientY are updated correctly)
alexreardon
Comment 6
2018-01-24 13:15:56 PST
Please let me know if there is any more information you need. It would be great to see this fixed! 😊
alexreardon
Comment 7
2018-02-21 13:37:53 PST
Any update on this one?
Toby Zerner
Comment 8
2019-10-29 18:11:17 PDT
Would love to see this fixed as there's not really a nice workaround. For now I've got this at the start of my touchmove event handler: let cancelNextMoveEvent = true; document.addEventListener('touchmove', function() { if (cancelNextMoveEvent) { cancelNextMoveEvent = false; return; } cancelNextMoveEvent = true; // my handler code }, { passive: false }); This means my handler will only be run on every second touchmove event, which seems to do the trick for the most part - but sometimes I do still get incorrect clientY values.
Jack Doyle
Comment 9
2022-03-02 16:22:38 PST
Any update on this? On latest iOS Safari I'm still getting this behavior quite regularly, especially if I move my finger quickly. The clientX/clientY can be WAY off (hundreds of pixels).
Jack Doyle
Comment 10
2022-03-03 21:31:35 PST
Another minimal test case:
https://codepen.io/GreenSock/pen/ExbrPNa/087cef197dc35445a0951e8935c41503?editors=0010
Radar WebKit Bug Importer
Comment 11
2022-03-30 17:25:15 PDT
<
rdar://problem/91075757
>
neil girardi
Comment 12
2022-12-28 06:56:19 PST
Is anyone taking action on this? It appears this issue has been open for four years. Thank you and Happy Holidays.
Jack Doyle
Comment 13
2022-12-28 14:07:07 PST
Yeah, this seems like a pretty major problem to leave unresolved for almost 5 years. Any updates?
Cassie Evans
Comment 14
2023-02-23 05:47:27 PST
Bumping. It would be amazing to get this fixed. 💜
Abrar Rahman Protyasha
Comment 15
2023-04-13 15:20:10 PDT
Hi all. I'm looking at this bug report and wanted to revive the conversation a little bit. My impression is that programmatic scrolling isn't synchronized with touch event location (client X/Y)? Here's a distilled test case:
https://codepen.io/aprotyas/pen/PoyZBKR
. Let me know if I'm mischaracterizing (or not capturing at all) the bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug