Trace of InputDelay tracing.

Deleted: trace_touchstart-delay.json.gz 349 KB

trace_touchstart-delay.json.gz 349 KB Download

Deleted: Screen Shot 2016-08-19 at 17.18.05.png 211 KB

	Screen Shot 2016-08-19 at 17.18.05.png 211 KB View Download

pontus.alexander@ Can you please try with the canary version on mac.

I've tried 52 in Stable on Linux and I see the 100ms delay. But with my ToT build the delay is 1.435ms

I belive some scheduling changes might have fixed this.

I have the same effect in 54.0.2833.0

Deleted: chrome_2016-08-20_10-22-16.png 67.0 KB

	chrome_2016-08-20_10-22-16.png 67.0 KB View Download

Deleted: chrome_2016-08-20_10-22-18.png 43.9 KB

	chrome_2016-08-20_10-22-18.png 43.9 KB View Download

I think this is expected. The scheduler defers most other tasks while a touch gesture is being established. The deferral ends either when the gesture has been established (e.g., we see touchmove events) or 100ms have passed. This policy helps to reduce main thread touch handler latency.

If you want to run some code in response to a touch event, either run it directly in the event handler or use requestAnimationFrame if it the code is related to animations.

Thank you for your feedback! 

However, I have three reasons for thinking this is still a bug.

1) An asynchronous network request is also delayed as demonstrated in this branch of the original reproduction case: https://github.com/pomle/chrome-touchstart-delay-repr/tree/network-example

The Readme has also been updated to reflect changes in reproduction steps.

2) According to user dtapu...@chromium.org this might not happen on ToT (which sounds great but I have not been able to try it yet).

3) Firefox does not display this behavior.

I understand that the bug might feel like it might not be a big problem, but when using WebRTC with touchstart it makes Chrome not usable for some applications. Recently I developed a NES-controller you could load up on your Android and play games on another computer's screen using WebRTC. But because the latency is irregular it did not work well enough in Chrome.

I wrote about that experience here if you want more context: https://medium.com/recreating-megaman-2-using-js-webgl/phone-browser-as-game-pad-for-your-big-screen-game-6d10c3d216d6#.d6njlqyb5

I also want to add that the original reproduction could be solved with requestAnimationFrame for the simple example, but it does not solve the example doing a network request.


Thank you

Could you try calling preventDefault() in the touchstart handler? That should also be a signal that no scroll gesture is about to happen.

Unfortunately, preventDefault() does not seem to have any effect.

Okay, we might need to tell the scheduler about that signal then.

I have a similar bug on Chrome for Mac. A number of canvas touch drawing libraries were broken by Chrome 53(?) - for example, http://intridea.github.io/sketch.js/ and http://soulwire.github.io/sketch.js/examples/drawing.html. To reproduce the problem, open the developer console, toggle the Device Toolbar, and then visit those pages and try to use the canvas. You'll get errors like the following:

Ignored attempt to cancel a touchstart event with cancelable=false, for example because scrolling is in progress and cannot be interrupted.

The touchmove event won't even fire because it now has to be marked as passive to do so. Basically, Chrome is giving scrolling priority over other touch handlers, making it impossible to implement these drawing apps.

If these applications are calling preventDefault on the first touchmove or touchstart, they should work.

The ideal solution here is to use touch-action:none (https://developer.mozilla.org/en-US/docs/Web/CSS/touch-action).

I'm unable to reproduce the issue though. Does this reproduce in Chrome 54?

I'm unable to reproduce the issue highlighted in #10 as well. Tried on 54.0.2832.2 Mac OS 10.11.8

This is still a problem on 55.0.2883.75 (64-bit)

Please test using this reproduction case at https://github.com/pomle/chrome-touchstart-delay-repr

Setting touch-events property, or running event.preventDefault() does not mitigate problem.

See these screenshots for expected behavior in Firefox vs Chrome
http://imgur.com/a/RtM4Z

If you can not reproduce using the reproduction case provided, please provide either a screen shot or a screen capture of the console output to verify we are testing and talking about the same effect.

 Issue 685613  has been merged into this issue.

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

commit cff6288fd965f274205ca6ab9cded462ba204dc9
Author: skyostil <skyostil@chromium.org>
Date: Sat Jan 28 13:18:04 2017

scheduler: Detect single event gestures correctly

When a single event gesture such as a press (i.e., a single touchstart
event) is observed, the scheduler would previously wait for two
subsequent touchmove events before deciding the gesture was established
and stop blocking tasks unrelated to input handling. The problem was
that with single event gestures, these additional events are never sent,
so the scheduler would remain in 'touchstart' mode for 100ms, possibly
causing important tasks to get delayed.

This patch fixes the issue by telling the scheduler how the touchstart
event was handled. If the event handler calls preventDefault() on the
event, the scheduler can immediately conclude that the gesture is
handled by the main thread without waiting for any further events. If
preventDefault() is not called, we maintain the previous behavior.

BUG= 639300 

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

[modify] https://crrev.com/cff6288fd965f274205ca6ab9cded462ba204dc9/content/renderer/input/input_event_filter.cc
[modify] https://crrev.com/cff6288fd965f274205ca6ab9cded462ba204dc9/content/renderer/input/input_event_filter.h
[modify] https://crrev.com/cff6288fd965f274205ca6ab9cded462ba204dc9/content/renderer/input/input_handler_manager.cc
[modify] https://crrev.com/cff6288fd965f274205ca6ab9cded462ba204dc9/content/renderer/input/input_handler_manager.h
[modify] https://crrev.com/cff6288fd965f274205ca6ab9cded462ba204dc9/content/renderer/input/input_handler_manager_client.h
[modify] https://crrev.com/cff6288fd965f274205ca6ab9cded462ba204dc9/content/renderer/input/main_thread_event_queue.cc
[modify] https://crrev.com/cff6288fd965f274205ca6ab9cded462ba204dc9/content/renderer/input/main_thread_event_queue.h
[modify] https://crrev.com/cff6288fd965f274205ca6ab9cded462ba204dc9/content/renderer/input/main_thread_event_queue_unittest.cc
[modify] https://crrev.com/cff6288fd965f274205ca6ab9cded462ba204dc9/content/renderer/input/render_widget_input_handler.cc
[modify] https://crrev.com/cff6288fd965f274205ca6ab9cded462ba204dc9/content/renderer/input/render_widget_input_handler_delegate.h
[modify] https://crrev.com/cff6288fd965f274205ca6ab9cded462ba204dc9/content/renderer/render_view_impl.cc
[modify] https://crrev.com/cff6288fd965f274205ca6ab9cded462ba204dc9/content/renderer/render_widget.cc
[modify] https://crrev.com/cff6288fd965f274205ca6ab9cded462ba204dc9/content/renderer/render_widget.h
[modify] https://crrev.com/cff6288fd965f274205ca6ab9cded462ba204dc9/third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl.cc
[modify] https://crrev.com/cff6288fd965f274205ca6ab9cded462ba204dc9/third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl.h
[modify] https://crrev.com/cff6288fd965f274205ca6ab9cded462ba204dc9/third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl_unittest.cc
[modify] https://crrev.com/cff6288fd965f274205ca6ab9cded462ba204dc9/third_party/WebKit/Source/platform/scheduler/test/fake_renderer_scheduler.cc
[modify] https://crrev.com/cff6288fd965f274205ca6ab9cded462ba204dc9/third_party/WebKit/public/platform/scheduler/renderer/renderer_scheduler.h
[modify] https://crrev.com/cff6288fd965f274205ca6ab9cded462ba204dc9/third_party/WebKit/public/platform/scheduler/test/fake_renderer_scheduler.h
[modify] https://crrev.com/cff6288fd965f274205ca6ab9cded462ba204dc9/third_party/WebKit/public/platform/scheduler/test/mock_renderer_scheduler.h

Note that the above fix only makes the preventDefault() path work -- touch-action will still needs to be addressed by  crbug.com/686110 .

Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

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

Please merge  your change to M57 branch 2987 ASAP.If merge happens today before 5:00 PM PT, then we can take it for tomorrow's last M57 Dev release. Thank you.

Please merge your change to M57 branch 2987 ASAP (latest before 5:00 PM PT on Wednesday, 02/01/17) so we can pick it up for M57 Beta promotion release this week. Thank you.

Not sure why it didn't show up here, but this was merged to M57 with https://codereview.chromium.org/2663283002/.

Per comment #23,this is already merged to M57.

Verified the issue on Mac 10.12.2 using 57.0.2987.21 and its working fine now.
Attached the screen cast for the same.

Deleted: 639300_Feb_2.mp4 568 KB

	639300_Feb_2.mp4 568 KB View Download