New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 699413 link

Starred by 2 users

Issue metadata

Status: Archived
Owner:
Closed: Mar 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Regression: Touchmove events are fired when stylus is moved

Project Member Reported by oka@chromium.org, Mar 8 2017

Issue description

Chrome Version: 56.0.2924.110
OS: Chrome OS 9000.91.0 stable-channel kevin.

What steps will reproduce the problem?
(1) Go to http://jsfiddle.net/vy8ecmyL/8/
(2) Move stylus on the canvas

What is the expected result?
Only #Pointermove is incremented as stylus moves.

What happens instead?
pointermove is fired only on the begining of a movement and touchevent is fired after that.



 

Comment 1 by oka@chromium.org, Mar 8 2017

I think this is a bug, because from TouchEvent the pressure (a unique feature of stylus) cannot be taken.

Comment 2 by oka@chromium.org, Mar 8 2017

Cc: tbuck...@chromium.org zalcorn@chromium.org
Labels: M-57
Summary: Regression: Touchmove events are fired when stylus is moved (was: Touchmove events are fired when stylus is moved)
Confirmed this is a regression.
The issue didn't reproduce in 55.0.2883.34. Chrome OS 8872.34.0 kevin.

This breaks Stylus app on demo mode, which runs on Chromebooks on retail stores. https://bugs.chromium.org/p/chromium/issues/detail?id=699413
There is little hope to workaround this because unlike pointerevent, touchevent doesn't have pressure, needed by the app.

Will it be possible to cherry-pick a fix to M57?

Comment 3 by oka@chromium.org, Mar 8 2017

Labels: -Pri-2 Pri-0
Cc: rbyers@chromium.org
Components: Blink>Input
Owner: mustaq@chromium.org
Status: Assigned (was: Untriaged)
I believe you need a touch-action: none set on the canvas. Have you tried that in your demo app?

ie; try this: http://output.jsbin.com/fitasewaqo
Code should be listening to either pointer events or touch events OR should be calling preventDefault on the pointerdown event to prevent touch events from being fired at all.  

But why would this have behaved that way in M55?  Should we request a bisect?

Comment 6 by mustaq@chromium.org, Mar 10 2017

oka@: The repro you sent has a few issues as dtapuska@ and rbyers@ mentioned above, the missing "touch-action:none" is the main one. But this shouldn't change after M55.

Could you please confirm if both:
  (a) the demo app you mentioned and
  (b) your repro above
show the regression?

Comment 7 by mustaq@chromium.org, Mar 10 2017

Cc: denniskempin@chromium.org

Comment 8 by oka@chromium.org, Mar 13 2017

Labels: -Pri-0 Pri-2
Thank you for the explanation. I will add touch-action to demo app to fix the issue in demo app.

Comment 9 by mustaq@chromium.org, Mar 13 2017

Status: Fixed (was: Assigned)
Seems we don't need any change in chromium, so closing the bug. Feel free to reopen if this is not the case.
Labels: VerifyIn-61

Comment 11 by dchan@chromium.org, Jan 22 2018

Status: Archived (was: Fixed)

Sign in to add a comment