touchmove Event interrupts during continuous draw
Reported by
julianri...@googlemail.com,
Jun 24 2018
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36 Example URL: http://268-multitouch-onescreen.e5j.de/ or https://keep.google.com Steps to reproduce the problem: 1. Open up http://268-multitouch-onescreen.e5j.de/ or https://keep.google.com (Draw new note) on a PC with Win 10, Chrome and a touchscreen. 2. Draw on the screen continuously. What is the expected behavior? We expect the line to follow the fingers during drawing - more or less independent to the speed we are drawing with. What went wrong? The lines follow our fingers. Then - if we move faster or begin to turn the directions of our fingers at random times the line begins to get stuck - and as we go on with drawing at some time the line "jumps" to our fingers again and goes on to follow our fingers correctly. We began to debug this problem and found that there were no touchmove-events beeing fired during the interruption. We then run a recording on the performance tab in developer tools, an we could see the interruption of touch input in "interaction"-panel. (see screenshot of the performance tab. It shows continuous drawing but the interaction panel shows interruptions). To look for driver / screen issues, we tested with different Touch-Screens (problem persisted), then we tested with Firefox - everything is fine there. Then we used Microsoft Paint - everything is fine there too. Both URLs work perfectly on Chrome for Android aswell. So it must have something to do with Chrome for Windows (Desktop). It works well when using touch emulation in dev tools or when using the mouse to draw. We then played around with different "touch-action" or "overscroll-behaviour" css rules. We even tried to mess around with all of the touch and scroll related flags in "chrome://flags". And we tried different settings related to event.preventDefault in the event handlers. Nothing helped - and now we are out of ideas. :( In "Any other comments" we provide videos of the behaviour. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? No Does this work in other browsers? Yes Chrome version: 67.0.3396.87 Channel: stable OS Version: 10.0 Flash Version: Problem in Chrome for Windows: https://www.dropbox.com/s/kb0dmr0bmyjykny/20180624_111031.mp4?dl=0 Slow drawing is OK - then it gets broken with faster moves: https://www.dropbox.com/s/jkq8e177ttioxi2/20180624_111042.mp4?dl=0 No Problems in Chrome when using Mouse: https://www.dropbox.com/s/n8hu7zmvx8l490o/no-problem-mouse.webm?dl=0 No Problems in Chrome when using Touch Emulation by dev tools: https://www.dropbox.com/s/0ym44wbtkfz7t3t/no-problem-touch.webm?dl=0 It works perfectly in Firefox: https://www.dropbox.com/s/kksylpuvqmmrzt9/20180624_110943.mp4?dl=0
,
Jun 24 2018
Did a little bit more testing. A simple "--disable-gpu" seems to solve the issue on all different PCs (all have NVidia or Intel Graphics). However, this is not as intended?
,
Jun 24 2018
Hey, The same issue is also prevalent on the Ubuntu operating system. This does not seem to be a Windows-specific bug.
,
Jun 24 2018
,
Jun 25 2018
,
Jun 26 2018
Able to reproduce the issue on chrome reported version# 67.0.3396.87 and latest chrome# 69.0.3472.0 using Windows-10 surface pro and ubuntu 17.10 with the URL: https://keep.google.com given in comment#0. As this issue is seen from M-60, hence considering this issue as Non-Regression and marking it as Untriaged. Note: Unable to provide behaviour of Mac, as TE team doesn't have Mac touch devices. Thanks!
,
Jun 28 2018
eirage@ based on the repo steps it looks like the issue is similar to your prediction work. Are you a proper owner for this?
,
Jun 28 2018
Looks like it's because of busy main thread and coalescing. Reporter: could you provide a tracing record from chrome://tracing?
,
Jun 28 2018
,
Jun 28 2018
will record it tomorrow when back in office.
,
Jun 30 2018
Will upload trace-files in different comments due to max_file_size
,
Jun 30 2018
Will upload trace-files in different comments due to max_file_size
,
Jun 30 2018
Will upload trace-files in different comments due to max_file_size
,
Jun 30 2018
Will upload trace-files in different comments due to max_file_size
,
Jun 30 2018
In the attached screenshot I show how I drawed during the traces. I began with drawing slow (no bug), then a fast section in the middle (bug appeared) and then slow again at the end. Slow areas in the screenshot are yellow, blue area is fast drawing. Big black lines are the lines that were drawn during the traces. the blue line was added in the screenshot only, so that you can see how my finger moved during the trace.
,
Jul 13
Are there any news on this?
,
Jul 30
Sorry for the delay! The tracing files you provided looks normal to me, and I wasn't able to reproduce this on windows device locally. Reporter: have you experience this on different devices? could this delay be a device issue? The line "jumping" you mentioned should be because of chrome coalesce input events and dispatch them per frame. You can try using PointerEvent.getCoalescedEvent api to get the full events info. See: https://developers.google.com/web/updates/2017/06/aligning-input-events
,
Aug 1
Hi, I was able to reproduce the issue on several different displays. However, on some the issue did not appear. What is strange about it: On every display tested, touch worked fluently using Firefox or even MS Paint. Only in Chrome there were interruptions drawing the lines. This was why I thought it must have something to do with chrome. As written above, viswa.karala@chromium.org was also able to reproduce. Can we deliver any more logs etc.? For the "getCoalescedEvent", we will have a look shortly.
,
Aug 21
I'm going to mark this as won't fix since this behavior is expected as the rAF aligned events. Reporter: feel free to comment on this if you have further question. |
||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||
Comment 1 by julianri...@googlemail.com
, Jun 24 2018546 KB
546 KB View Download