android webview loads some moblie pages,touch event handles those pages,it costs more times.if timeout ,touchcancel happened and discard all touches which in queues.but if timeout unactive,then no touchcancel happened,all touchevent will happen.it will make thread more busy.so i think that touch timeout is necessary on android webview.

In most WebView scenarios, the Android app developer has complete control over the web contents, correct?

It's an interesting question whether we should apply interventions at all in WebView. I can see an argument that the expectations for Android apps and requirements for Android app developers are different than general websites, thus we should never apply interventions in WebViews.

On the other hand, I expect there are a reasonable number of WebViews containing terrible content.

I suspect we should be fairly consistent with our application of interventions in WebView – either applying them the same way as we do in Chrome, or not at all.

A significant proportion of WebView usage (probably a majority) is for ads and other third party content.

Our default position is that we want WebView to behave like Chrome, except where we have some actual reason to believe that it'll break apps in the wild.

Also yes, even when the developer controls the content it's very often terrible content :)

aelias@, why are you thinking there isn't much reason to apply the timeout on WebView?

If WebView frequently contains bad content, we might as well apply interventions in the same way as Chrome.

I like the principle of WebView matching Chrome unless there's a good reason otherwise (more predictable for developers that way).  But I can see the argument for disabling a few interventions in WebView.   Touch timeout is hopefully close to being replaced with Tim's better intervention, so the downsides of having the intervention should be MUCH lower.

+one for matching chrome

I don't think there is a good reason to diverge here.

I think Touch timeout is necessary, webview should consistent with chrome at current time.
When a lot of touchs in queues,with out touch timeout，these touchs should exctue.In this case,another touch comes in,it will response after a long times.It will not response immediately for user until the touches which in queue has done,this is very terrible.

The touch timeout makes this actively less predictable so the predictability argument cuts both ways.  Anyway, fine, I don't feel very strongly about this, just wanted to raise the question.

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

commit e68beb5d5b4092c21ff77c0b9db69c4729bc99b9
Author: johnstonli <johnstonli@tencent.com>
Date: Mon Sep 12 04:02:30 2016

Add mobile optimized to TouchEvent Timeout For Android WebView

Due to an unfortunate factoring oversight, the InputRouter was never informed of the
mobile-optimized status from frame metadata.  This means that the touch event
timeout was globally applied for Android WebView.

This patch forwards the notification appropriately to the input router, so
that the timeout is limited to when viewing oversized ("desktop") pages in
WebView (just like in Chrome for Android).

BUG= 645337 

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

[modify] https://crrev.com/e68beb5d5b4092c21ff77c0b9db69c4729bc99b9/AUTHORS
[modify] https://crrev.com/e68beb5d5b4092c21ff77c0b9db69c4729bc99b9/content/browser/renderer_host/render_widget_host_view_android.cc