Sadrul, do you know who would understand this issue? It looks like either Chrome or Blink, but not sure which.

This sounds like the bug we have been discussing in an off-list thread. There is a chance this is related to touch-text-selection feature, but it's unclear. We need someone to spend time on figuring out what is causing the issue.

kuscher@ Perhaps you could find someone to look into it?

+Albert who may be able to help

jdufault@ can you dig into this?

mfomitchev@ or mohsen@ any thoughts on this from the touch text selection perspective?

I'll try to take a look later this week. Is this going to be a beta/stable release block?

Good catch. This really shouldn't hit stable.

I checked on a samus....it happens on samus also on M51 8161.0.0 and doesn't happen on M50 7978.57.0 beta build.

I'd look into whether we are getting stuck in a nested message loop and poke around the menu code. Also +jonross who's been working on the menu code recently and might have some insight.
I doubt this has to do with text selection. The only thing in text selection I can think of, which could conceivably interfere with input this way is LongPressDragSelector, but that's not used on CrOS.
I am on vacation now and until the end of the week, so won't be able to help much with this unfortunately.

I'll roll a build to see if the menu is shutting down properly.

Has this only been seen on CrOS?

The context menu is properly shutting down the nested message loop, and releasing input capture.

Touch is able to target other tabs/ui elements.

It appears that something within the content area stops responding to touch. Or it could be in a confused state if it is expecting certain inputs and the context menu launching changed that.

Sounds like we need someone to trace this into blink.

+a few folks who might be able to help dig into this.

First, this is not related to touch selection. I commented out touch selection code and I could still repro the issue.

Second, I think r381540 is the culprit. It sets |gesture_target_| to nullptr in RenderWidgetHostInputEventRouter::RoutGestureEvent() and the rest of gesture events are ignored (just gesture events, not touch events). This patch probably surfaces another underlying issue since the line that sets |gesture_target_| is apparently not meant to be hit.

+wjmaclean

The setting of gesture_target_ to null should (in theory) only affect the current gesture sequence, as a new gesture_target_ is set when the next touch sequence is seen. If gesture_target_ is never getting set to a new value, then it sounds as if we're not seeing a new touch_target_ either ... has anyone checked this?

James it seems pretty likely that this is related to your change.

Can you dig into this?

Ok, I've triaged this a bit further, and what's happening is this:

1) RenderWidgetHostInputEventRouter::RouteTouchEvent() gets called with a TouchStart event.

2) If the touch persist long enough to trigger a context menu (GestureLongPress), then GestureRecognizerImpl::CancelActiveTouches() is invoked to send a TouchCancel to balance off the TouchStart received earlier.

3) Although this all works as intended on a regular Linux build, on a CrOS build on Linux we hit the following early-out in CancelActiveTouches()

https://code.google.com/p/chromium/codesearch#chromium/src/ui/events/gestures/gesture_recognizer_impl.cc&rcl=1461151052&l=164

4) This results in the RWHIER never receiving a touchEnd/Cancel, and since its active_touches_ count never goes to 0, it tries to continue a touch sequence that will never end.

In this event, RWHIER is behaving as expected.

Looking at git-blame shows no recent changes to the pointer_state code in the vicinity of the early out, but I'm pretty sure my recent changes do not cause this bug, though they give it an avenue for expression.

As a hack-z-periment, I instead forced sending of a TouchCancel with Point(0,0) and touch_id = 0 and this restores proper touch functionality to the page.

I really know nothing about pointer_state, so I'd like to punt on this one.

tdresser@ - could you reassign it to someone with pointer_state knowledge?

James - have you tried to repro with your change reverted?

No, but I can pretty much guarantee that reverting r381540 doesn't fix the problem, as we're still left stuck with the issue that the RWHIER never completes the active touch sequence, so no new touch_target or new gesture_target will be possible.

I tried the revert, and it *appears* to work, but here's the thing: it appears to work only because we continue to use whatever the previous gesture target was, so on a page with a WebView or an OOPIF iframe this will have the potential to fail in strange ways, as the gesture target will be forever locked to what it was when the GestureLongPress occurred.

I addition, it also causes the following NOTREACHED() to be hit:

[18522:18522:0420/160532:ERROR:tap_suppression_controller.cc(109)] NOTREACHED() hit.

I think the correct way to move forward with this is to find why the pointer_state is empty when we attempt to send the CancelActiveTouches(). We could attempt a temporary patch of *always* sending a touch cancel even if the pointer state is empty, though I have no idea what the potential side effects of that might be ...

Thanks for digging into this James.

I'll take a look.

This is actually a bug in transferring gesture streams between windows, which has been around for a long time.

I've got a solution in the works.

This appears to be the same issue as  crbug.com/446852 .

It isn't as simple as I was thinking initially.

 Issue 609666  has been merged into this issue.

 Issue 600695  has been merged into this issue.

 Issue 609281  has been merged into this issue.

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

commit 4ab3ab417ec9ddaa3672219ea3dba4e8b35f1518
Author: tdresser <tdresser@chromium.org>
Date: Fri May 13 17:40:10 2016

Drag and drop cleans up touch sequences from the source window.

Previously we would just leave the source window thinking it had
a pointer touching it the whole time, and then when a new pointer
came down, we'd ignore that event. This behavior is required for
tab drag, but not for drag and drop.

This caused problems for OOPIF/webview event targetting.

This patch sends cancel events correctly in the drag and drop
case. This is a bit tricky, because during drag and drop, we move
a gesture recognizer from the source window to the destination
window, leaving the source window with no gesture recognition
state. To deal with this, we send press events to the gesture
recognizer without sending them to the associated window, to get
the gesture recognizer state for the source window back in sync
with the pointers that are active on it, and then we dispatch
cancel events to the source window.

Ideally we'd just clone the GR state and then send the cancel
events, but cloning the GR state would be painful.

The tab drag case is left untouched - when dragging a tab,
the source window continues to think that a pointer is down
throughout the tab drag, until the finger is raised.

BUG= 604454 
TEST=GestureProviderAuraTest.IgnoresExtraPressEvents, GestureRecognizerTest.PressDoesNotCrash

Review-Url: https://codereview.chromium.org/1907323003
Cr-Commit-Position: refs/heads/master@{#393568}

[modify] https://crrev.com/4ab3ab417ec9ddaa3672219ea3dba4e8b35f1518/ash/drag_drop/drag_drop_controller.cc
[modify] https://crrev.com/4ab3ab417ec9ddaa3672219ea3dba4e8b35f1518/ash/shelf/shelf_tooltip_manager_unittest.cc
[modify] https://crrev.com/4ab3ab417ec9ddaa3672219ea3dba4e8b35f1518/chrome/browser/ui/views/tabs/tab_drag_controller.cc
[modify] https://crrev.com/4ab3ab417ec9ddaa3672219ea3dba4e8b35f1518/ui/aura/gestures/gesture_recognizer_unittest.cc
[modify] https://crrev.com/4ab3ab417ec9ddaa3672219ea3dba4e8b35f1518/ui/aura/window_event_dispatcher.cc
[modify] https://crrev.com/4ab3ab417ec9ddaa3672219ea3dba4e8b35f1518/ui/aura/window_event_dispatcher.h
[modify] https://crrev.com/4ab3ab417ec9ddaa3672219ea3dba4e8b35f1518/ui/events/gesture_detection/gesture_provider.cc
[modify] https://crrev.com/4ab3ab417ec9ddaa3672219ea3dba4e8b35f1518/ui/events/gestures/gesture_provider_aura.cc
[modify] https://crrev.com/4ab3ab417ec9ddaa3672219ea3dba4e8b35f1518/ui/events/gestures/gesture_provider_aura.h
[modify] https://crrev.com/4ab3ab417ec9ddaa3672219ea3dba4e8b35f1518/ui/events/gestures/gesture_provider_aura_unittest.cc
[modify] https://crrev.com/4ab3ab417ec9ddaa3672219ea3dba4e8b35f1518/ui/events/gestures/gesture_recognizer.h
[modify] https://crrev.com/4ab3ab417ec9ddaa3672219ea3dba4e8b35f1518/ui/events/gestures/gesture_recognizer_impl.cc
[modify] https://crrev.com/4ab3ab417ec9ddaa3672219ea3dba4e8b35f1518/ui/events/gestures/gesture_recognizer_impl.h
[modify] https://crrev.com/4ab3ab417ec9ddaa3672219ea3dba4e8b35f1518/ui/events/gestures/gesture_recognizer_impl_mac.cc
[modify] https://crrev.com/4ab3ab417ec9ddaa3672219ea3dba4e8b35f1518/ui/events/gestures/gesture_types.h
[modify] https://crrev.com/4ab3ab417ec9ddaa3672219ea3dba4e8b35f1518/ui/events/gestures/motion_event_aura.cc
[modify] https://crrev.com/4ab3ab417ec9ddaa3672219ea3dba4e8b35f1518/ui/events/gestures/motion_event_aura_unittest.cc

I still need to test this in an actual Chrome OS release, but adding Merge-Request label now.

Tested tab dragging case on Windows Canary.

Your change meets the bar and is auto-approved for M51 (branch: 2704)

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

commit bbe2f039113871b17b7ce6a3ab243eb9432d4720
Author: Tim Dresser <tdresser@chromium.org>
Date: Wed May 18 18:43:11 2016

Drag and drop cleans up touch sequences from the source window.

Previously we would just leave the source window thinking it had
a pointer touching it the whole time, and then when a new pointer
came down, we'd ignore that event. This behavior is required for
tab drag, but not for drag and drop.

This caused problems for OOPIF/webview event targetting.

This patch sends cancel events correctly in the drag and drop
case. This is a bit tricky, because during drag and drop, we move
a gesture recognizer from the source window to the destination
window, leaving the source window with no gesture recognition
state. To deal with this, we send press events to the gesture
recognizer without sending them to the associated window, to get
the gesture recognizer state for the source window back in sync
with the pointers that are active on it, and then we dispatch
cancel events to the source window.

Ideally we'd just clone the GR state and then send the cancel
events, but cloning the GR state would be painful.

The tab drag case is left untouched - when dragging a tab,
the source window continues to think that a pointer is down
throughout the tab drag, until the finger is raised.

BUG= 604454 
TEST=GestureProviderAuraTest.IgnoresExtraPressEvents, GestureRecognizerTest.PressDoesNotCrash

Review-Url: https://codereview.chromium.org/1907323003
Cr-Commit-Position: refs/heads/master@{#393568}
(cherry picked from commit 4ab3ab417ec9ddaa3672219ea3dba4e8b35f1518)

Review URL: https://codereview.chromium.org/1987343002 .

Cr-Commit-Position: refs/branch-heads/2704@{#586}
Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251}

[modify] https://crrev.com/bbe2f039113871b17b7ce6a3ab243eb9432d4720/ash/drag_drop/drag_drop_controller.cc
[modify] https://crrev.com/bbe2f039113871b17b7ce6a3ab243eb9432d4720/ash/shelf/shelf_tooltip_manager_unittest.cc
[modify] https://crrev.com/bbe2f039113871b17b7ce6a3ab243eb9432d4720/chrome/browser/ui/views/tabs/tab_drag_controller.cc
[modify] https://crrev.com/bbe2f039113871b17b7ce6a3ab243eb9432d4720/ui/aura/gestures/gesture_recognizer_unittest.cc
[modify] https://crrev.com/bbe2f039113871b17b7ce6a3ab243eb9432d4720/ui/aura/window_event_dispatcher.cc
[modify] https://crrev.com/bbe2f039113871b17b7ce6a3ab243eb9432d4720/ui/aura/window_event_dispatcher.h
[modify] https://crrev.com/bbe2f039113871b17b7ce6a3ab243eb9432d4720/ui/events/gesture_detection/gesture_provider.cc
[modify] https://crrev.com/bbe2f039113871b17b7ce6a3ab243eb9432d4720/ui/events/gestures/gesture_provider_aura.cc
[modify] https://crrev.com/bbe2f039113871b17b7ce6a3ab243eb9432d4720/ui/events/gestures/gesture_provider_aura.h
[modify] https://crrev.com/bbe2f039113871b17b7ce6a3ab243eb9432d4720/ui/events/gestures/gesture_provider_aura_unittest.cc
[modify] https://crrev.com/bbe2f039113871b17b7ce6a3ab243eb9432d4720/ui/events/gestures/gesture_recognizer.h
[modify] https://crrev.com/bbe2f039113871b17b7ce6a3ab243eb9432d4720/ui/events/gestures/gesture_recognizer_impl.cc
[modify] https://crrev.com/bbe2f039113871b17b7ce6a3ab243eb9432d4720/ui/events/gestures/gesture_recognizer_impl.h
[modify] https://crrev.com/bbe2f039113871b17b7ce6a3ab243eb9432d4720/ui/events/gestures/gesture_recognizer_impl_mac.cc
[modify] https://crrev.com/bbe2f039113871b17b7ce6a3ab243eb9432d4720/ui/events/gestures/gesture_types.h
[modify] https://crrev.com/bbe2f039113871b17b7ce6a3ab243eb9432d4720/ui/events/gestures/motion_event_aura.cc
[modify] https://crrev.com/bbe2f039113871b17b7ce6a3ab243eb9432d4720/ui/events/gestures/motion_event_aura_unittest.cc

verified on 51.0.2704.55 / 8172.39.0