Always reset touch action at the beginning of a new gesture sequence

content/browser/renderer_host/input/input_router_impl.cc

 // Copyright 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/browser/renderer_host/input/input_router_impl.h"
 
 #include "base/auto_reset.h"
 #include "base/command_line.h"
 #include "base/metrics/histogram.h"
 #include "base/strings/string_number_conversions.h"
@@ skipping 268 matching lines @@
       return;
     }
     mouse_move_pending_ = true;
   }
 
   FilterAndSendWebInputEvent(mouse_event.event, mouse_event.latency, false);
 }
 
 void InputRouterImpl::SendTouchEventImmediately(
     const TouchEventWithLatencyInfo& touch_event) {
+  if (WebInputEventTraits::IsNewTouchSequence(touch_event.event))

[jdduke (slow), 2014/02/21 15:45:33]

Hmm, what if the touch handler is removed during a touch sequence?  On the next
touch sequence, we won't forward any touches, but we'll still have the touch
action from the previous sequence?

[jdduke (slow), 2014/02/21 15:50:10]

Hmm, we should probably have |OnHasTouchEventHandlers()| update
TouchActionFilter in some fashion regardless of this change?

[tdresser, 2014/02/21 19:14:03]

In theory OnHasTouchHandlers should be completely irrelevant to touch-action.
See crbug.com/329566 for context. 

[Rick Byers, 2014/02/21 19:52:13]

I think Jared is right here - good catch!  The problem is that if we reset the
touch action on the START of a touch sequence, then anything that filters out
touch sequences (like TouchEventQueue does in various ways) can cause us to miss
this start.  crbug.com/329566 is about compositor touch hit testing (where we
have a fast path on the impl thread).  Jared is talking about the (older) fast
path where we avoid sending touch events to the renderer entirely when we know
there are no touch handlers at all.  TouchEventQueue should be free to drop
touch events for other reasons too (thought I don't think it drops touchstart
for any other case today).

Perhaps a better fix is to reset the touch action on touch sequence end (since
if SetTouchAction was called, then a touchstart reached the renderer, and so
_some_ ending event for the sequence must as well).  We'll have to be careful
not to end pre-maturely on synthetic touchcancel cases.  This may prove
problematic too.

Or maybe we really do need to plumb GestureEnd (for the last finger) through (as
recently came up in one of Zeeshan's patches too).  Having a 'all fingers have
left the screen' gesture event could be usefulll...

Alternately hooking just OnHasTouchEventHandlers as Jared suggests is workable
as well, but feels like a hack that could be brittle.

+    touch_action_filter_.OnStartNewTouchSequence();
+
   FilterAndSendWebInputEvent(touch_event.event, touch_event.latency, false);
 }
 
 void InputRouterImpl::SendGestureEventImmediately(
     const GestureEventWithLatencyInfo& gesture_event) {
   FilterAndSendWebInputEvent(gesture_event.event, gesture_event.latency, false);
 }
 
 const NativeWebKeyboardEvent* InputRouterImpl::GetLastKeyboardEvent() const {
   if (key_queue_.empty())
@@ skipping 464 matching lines @@
       break;
   }
 }
 
 bool InputRouterImpl::IsInOverscrollGesture() const {
   OverscrollController* controller = client_->GetOverscrollController();
   return controller && controller->overscroll_mode() != OVERSCROLL_NONE;
 }
 
 }  // namespace content