Could you link to your test case that you're using in the video?

Hi 

Here's a link to the test case: https://s3.amazonaws.com/kamimiscpublic/CodePen+-+double+touch.htm

Thanks
Jordan

(Also, the reported platform for this issue is wrong. It's actually Chrome OS 69 on the  Asus C213SA-YSO2-S, using an EMR stylus)

Hi, Any luck testing this with the new link?

Cheers

(Feedback posted)

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I couldn't repro, trying to make a simpler one.

I couldn't repro.  Wondering if the repro in #c3 is the source of the bug!

jordan@kamihq.com: Could you please see if the following alternate repro shows the bug?  Here a single-touch shouldn't have any of the 3 numbers greater than one.

https://codepen.io/mustaqahmed/full/vzrRGB

Hi

I was able to reproduce this on your codepen: When I have one finger on the screen scrolling, and I tap with the stylus (down then up quickly one tap), then keep scrolling with finger, it does create the numbers (2,1,2), and then every scroll after that with one finger produces (2,1,2). As before when it happens I can tap with 2 fingers and it resets it to (1,1,1) again.

You may need to try a few different tabs to get this to happen.
Here's a video of it happening: https://photos.app.goo.gl/PAgM5LCvYaHoCBmq7

Which device are you testing on? We are seeing this issue on a Asus C213SA-YS02-S, platform: 10895.49.0 (Official Build) beta-channel reef-unibuild (electro basking pyro sand snappy alan bigdaddy)

Thanks

I can't repro yet, using a Samsung Chromebook Plus!

jordan@kamihq.com: Your video makes me think that the pen tap may be registering incorrectly as a touch at certain "touchstart" events.  I need few more details since I can't repro:

[1]
> You may need to try a few different tabs to get this to happen.
Does it mean even your device doesn't repro it every time?

[2]
I have changed my codepen above to dump pointer events and to change touch event info.  Now, you will see a 2+-element list of "ids" for a single finger drag when the bug hits you (like "touchmove ids=[#,#] ...").

Could you please attach a dump of the whole event log (I mean a copy of the right "yellow" div) when it happens?

Hi
1) I'm not entirely sure of whether tabs have an affect but it'sometimes quite hard to reproduce, I can confirm I am eventually able to replicate it on every tab if tried enough times.

2) Logs are attached for when it happens, I had to tap the stylus a few times for it to occur. Not included in the logs is that if I tap the screen with 2 fingers it will reset touchmove ids back to just having one of them, which is the same behavior I experienced with the bug in my own app, it will reset if tapped with more fingers.

Also note that this bug cannot be replicated on a pixel book with stylus.

Also the second touch (the non-existent one) in the touches list for subsequent one finger scrolling always has the same x,y values as well as a touch area of exactly 0.5 which makes me suspect the browser just didn't detect the stylus lifting off the screen and is thinking it is still touching the screen and stationary. Also attached are json objects of e.touches touchstart events for a one finger drag after the bug happens, I've attached 3 of them as you can see in each new finger swipe in the touches list it contains an identical touch thats not supposed to be there.

I hope this helps.

Deleted: logs.txt 6.6 KB

logs.txt 6.6 KB View Download

Deleted: touchstart event touches.txt 2.4 KB

touchstart event touches.txt 2.4 KB View Download

Thanks, here is the same log with the buggy "touchstart" highlighted:

https://docs.google.com/document/d/1r3wLEK_JluXbkxDmXiRXyeL-cphDzf-hUJ4tLYWr5lI/edit?usp=sharing

Two issues here:
- In the log, pointerType="pen" is reported only for the first pen interaction.  The rest are "touch".
- The buggy "touchstart" seems like a duplicate one sent too early.

Looks like an issue with hardware/firmware (touch digitizer/pen driver).

Dropping the priority since can't repro.

Hi

We have some new testing devices now, and this issue is also happening on the Acer CP311 N17Q8 and the Samsung Chromebook Pro v2 (XE510C25). As noted before, we are unable to replicate this on the PixelBook. Maybe it's caused by some common hardware to these new EMR devices?

Samsung Chromebook Pro v2: It reproduced with the built-in stylus, right?  That's odd since I tried an (older) Chromebook Plus which I assume similar!

I will give it another try.

Yes on the Chromebook Pro v2 I can replicate it both with the built-in stylus and a third party EMR one (Staedtler). It's actually very easy to cause this bug to happen on that hardware, seems easier than the Asus or Acer chromebooks.

It might not happen on the first generation device though if they changed the stylus hardware in the 2nd gen.

I was able to reproduce on two EMR devices.  Looking at the evdev reports, it happens whenever you tap very fast and BTN_TOOL_PEN (denoting a close pen, possibly hovering) and BTN_TOUCH (denoting a physical touch) occur in the same report.

I suspect this is a bug in the touch converter:
https://cs.chromium.org/chromium/src/ui/events/ozone/evdev/touch_event_converter_evdev.cc

When parsing evdev reports, it may see the BTN_TOUCH event before the BTN_TOOL_PEN event and interpret it as a finger contact, instead of a pen.  I'll look closer.

Fantastic that you were able to reproduce it, worried we might be going crazy over here  :)

Let me know if there's any info we can provide that might be helpful.

Assigning to seobrien@ who has successfully reproduced and also found the root cause.  Thanks.

+spang@

Here's where I'm at:

It looks like this bug was revealed with this CL: crrev.com/c/961386

We now post a task to disable the touchscreen when a pen is detected.  This means in the case when the pen touches the screen at the same time it is first detected, the touchscreen is disabled after the first pen event.

So we end up sending a cancel for the finger after sending a start for the pen, and blink can't handle cancelling one touch without cancelling them all (crbug.com/852022).

spang, can you take a look?

Is the problem that we're not sending the cancel or is the problem that the cancel is sent but not handled correctly?

As of now, blink expects all touches to be cancelled if any are cancelled.  It would be nice to have single-touch cancellation, but mustaq says in crbug.com/852022 that this will be quite a bit of work.

In this case, we send a cancel for the finger touch after the pen touch has landed, and we don't send a cancel for the pen touch.

If we're sending the cancel, then I think we've done all we can do at a low level. It sounds like the bug is that the cancel turns into a ghost contact higher in the stack.

If blink wants to cancel all touch points whenever any touch point is cancelled, it's possible to do that. But it needs to handle the cancel somehow; dropping it on the floor will lead to bugs like this one.

I'm much less familiar with that code, so kicking it back up the stack..

Hello is this an update on this bug? It would be great if we could get it prioritized. Here's an update on the impact of this bug from Kami:

We have some telemetry we added for how often users are hitting this bug - it's being triggered ~5000 times per week, from ~3500 unique users.  This bug affects all stylus drawing apps - I was just able to replicate it on the Google Keep chrome app, and the app is frozen for drawing and scrolling until I close it and reopen the app. (Here's a video of that: https://www.youtube.com/watch?v=hxf7lr2I2rk&feature=youtu.be ).

Hi, any updates on this? We're still getting reports of this from our users, and there is no viable workaround we can implement for it.

Assigning to nzolghadr@ who plans to look into the related Issue 852022.

Issue 852022 should be a blocker for this as per #c24.  But may be there is an easier way for this before we fix that one (e.g. consider partial "cancel" plumbing to blink to update the counts only).

We will get to this issue in 2019 Q1.