shend@: could you double check the chrome version. In your report, the chrome version is 70.0.3536.0, but your bisect result is pointed to a CL that is in 70.0.3537.0.

Hmm, version seems to be correct. When I checkout that revision and deploy it to a device, my chrome://version says:

Google Chrome: 70.0.3536.0 (Official Build) unknown (64-bit)
Revision: 45630997c15b80dec5d37add5a2f685e91548327 - refs/head/master@{#587259}

IDK why omaha reports 70.0.3537.0 :/

This issue should still repro on ToT. Can you confirm that you can repro it? I can attach a video of the issue if it helps...

I have attached a video which is a screencast. This is on ToT using stylus, and I cannot repro the bug...
Could you try on ToT?

Deleted: Screencast 2018-09-06 10:46:21.mp4 991 KB

	Screencast 2018-09-06 10:46:21.mp4 991 KB View Download

OK, sorry, my mistake.

Got help from eirage@. Apparently we disable the ontouch* API on 70, which is why this is failing.
https://www.chromestatus.com/feature/4764225348042752

To make this work, change the "var isTouchSupported = 'ontouchstart' in window;" to "var isTouchSupported = window.TouchEvent;", then the demo will work.

Please let me know if that solves the problem.

Thanks Xida. Based on your suggestion, it looks like the problem is that we are using pointer events and not touch events.

What is happening is that when the stylus moves too far away from its starting point, a `pointerout` event is triggered. This is because the browser now thinks that you are using the stylus to scroll the page. From [1], it sounds like this is WAI.

However, we have been using pointer events for quite a while with no problems. I don't know why it worked (and maybe it shouldn't work). But after 45630997c15b80dec5d37add5a2f685e91548327, it stops working due to the reason above (I'm pretty sure that's the correct CL, because I manually reverted it and the keyboard is working again...).

So my question is: was that CL intentionally changing the pointerout behaviour? Based on the CL description, I would think that it should only affect VR mode?

If it was an intentional change, then we'll have to change the virtual keyboard to use touch events. It would fix our virtual keyboard, but there may be other broken web apps out there.

If it wasn't, then is it possible to fix this on the Chromium input side or revert the CL?

It's a just a bit unfortunate that this behaviour change occurred right before branch point and made it into M70 :/

Thanks!

[1] https://developer.mozilla.org/en-US/docs/Web/Events/pointerout

If it helps, here are the expected/actual results for virtual keyboard. Notice how we can't draw a stroke that is too far away from the starting point.

Deleted: actual.webm 2.1 MB

	actual.webm 2.1 MB View Download

Deleted: expected.webm 1.2 MB

	expected.webm 1.2 MB View Download

I think you mean pointercancel?

Not sure if I repro this correctly, but from my understanding the test page use preventDefault on touchstart to make the touch not trigger scrolling, so there will be no pointercancel and pointermove fire continuously.
But at M70, 'ontouchstart' in window;" is false, and the prevent default at touch start is not added, which result in scrolling instead of drawing.

If only reverting Xida's patch will fix this ('ontouchstart' in window" is still false) , there may be something else that I didn't notice.

Sorry for the confusion, the demo page was a red herring, my mistake. Probably best to ignore the demo :P I just randomly found a demo online because I thought it had the same root cause as the virtual keyboard issue, but it turns out to be a different issue.

So there was no regression in the case of the demo, but there was a regression in the case of the virtual keyboard.

I'll try and come up with a test case.

Alright, I found the root cause. This is only an issue with the virtual keyboard (yay?)

Normally, when I tap my stylus and move it around a web page, TouchActionFilter::FilterGestureEvent [1] will receive two events:

1. kGestureTapDown
2. kGestureScrollBegin

However, in the virtual keyboard window, we explicitly block certain gesture events from reaching the virtual keyboard extension [2]. This was apparently to fix a crash. This means that when I tap and move, TouchActionFilter::FilterGestureEvent will only receive one event:

1. kGestureScrollBegin

This was working fine for some reason, until [3] changed this behaviour, by calling SetTouchAction(cc::kTouchActionAuto) when it sees a kGestureScrollBegin without kGestureTapDown. I assume [3] was meant to fix something related to VR, but it looks like events from the virtual keyboard also goes through this path.

I'm not really sure what the correct fix is. Some options:
1. Don't block gesture events in the virtual keyboard...could cause things to crash again, but doesn't seem to crash when I test locally :/
2. Just block long press since that seemed to be the main issue? Again, not sure what the impact on the keyboard would be.
2. Can [3] be rewritten so that it doesn't affect virtual keyboard events?

Anyway, sorry for the red herring with the demo. I think this is only a problem with the virtual keyboard because we are doing something crazy :P

[1] https://cs.chromium.org/chromium/src/content/browser/renderer_host/input/touch_action_filter.cc?type=cs&q=touchactionfilter&sq=package:chromium&g=0&l=48
[2] https://cs.chromium.org/chromium/src/chrome/browser/ui/ash/chrome_keyboard_web_contents.cc?sq=package:chromium&g=0&l=114
[3] https://crrev.com/45630997c15b80dec5d37add5a2f685e91548327

Is it possible to add VR flags guard here:

// In VR, GestureScrollBegin could come without GestureTapDown.
if (!gesture_sequence_in_progress_) {
  gesture_sequence_in_progress_ = true;
  SetTouchAction(cc::kTouchActionAuto);
}

shend@: you info is really helpful. I think I know how to fix this.

 Issue 881203  has been merged into this issue.

 Issue 880718  has been merged into this issue.

 Issue 880702  has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/166974eac5f60b21f29aa5dd3b0eae7b75224ba5

commit 166974eac5f60b21f29aa5dd3b0eae7b75224ba5
Author: Xida Chen <xidachen@chromium.org>
Date: Mon Sep 10 21:02:35 2018

Do not set touch action to Auto at GSB if it is already set

In chrome VR or virtual keyboard case, we can get GestureScrollBegin
without GestureTapDown, and that |scrolling_touch_action_| may have no
value. In this case, we set it to Auto to prevent crash. This was done
in a previous CL:
https://chromium-review.googlesource.com/c/chromium/src/+/1195649

However, there was a small mistake in the previous CL. That is, the
|scrolling_touch_action_| could have been set when the browser receives
the ACK for the touch start from the main thread. In this case, we should
not set it to Auto.

Bug:  880701 
Change-Id: I250bb7a09840f16665cfcf5826236cad99b533c5
Reviewed-on: https://chromium-review.googlesource.com/1213502
Reviewed-by: Navid Zolghadr <nzolghadr@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Xida Chen <xidachen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#590059}
[modify] https://crrev.com/166974eac5f60b21f29aa5dd3b0eae7b75224ba5/content/browser/renderer_host/input/touch_action_filter.cc
[modify] https://crrev.com/166974eac5f60b21f29aa5dd3b0eae7b75224ba5/content/browser/renderer_host/input/touch_action_filter_unittest.cc

The new CL seems to have fixed it :D Requesting merge for c#19, thanks!

cindyb@: could you take a look at the merge request? This bug is on chrome os

Verified this is fixed @ Chrome 71.0.3550.0 on a kevin with Platform 11042.0.0.

Can someone approve the merge request?

Your change meets the bar and is auto-approved for M70. Please go ahead and merge the CL to branch 3538 manually. Please contact milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop)

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

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/47c0af5fd304d381f8e287a44f2962514cce45dd

commit 47c0af5fd304d381f8e287a44f2962514cce45dd
Author: Xida Chen <xidachen@chromium.org>
Date: Wed Sep 12 04:17:29 2018

[Merge M70] Do not set touch action to Auto at GSB if it is already set

In chrome VR or virtual keyboard case, we can get GestureScrollBegin
without GestureTapDown, and that |scrolling_touch_action_| may have no
value. In this case, we set it to Auto to prevent crash. This was done
in a previous CL:
https://chromium-review.googlesource.com/c/chromium/src/+/1195649

However, there was a small mistake in the previous CL. That is, the
|scrolling_touch_action_| could have been set when the browser receives
the ACK for the touch start from the main thread. In this case, we should
not set it to Auto.

Bug:  880701 
Change-Id: I250bb7a09840f16665cfcf5826236cad99b533c5
Reviewed-on: https://chromium-review.googlesource.com/1213502
Reviewed-by: Navid Zolghadr <nzolghadr@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Xida Chen <xidachen@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#590059}(cherry picked from commit 166974eac5f60b21f29aa5dd3b0eae7b75224ba5)
Reviewed-on: https://chromium-review.googlesource.com/1220986
Reviewed-by: Darren Shen <shend@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#311}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
[modify] https://crrev.com/47c0af5fd304d381f8e287a44f2962514cce45dd/content/browser/renderer_host/input/touch_action_filter.cc
[modify] https://crrev.com/47c0af5fd304d381f8e287a44f2962514cce45dd/content/browser/renderer_host/input/touch_action_filter_unittest.cc