- Windows Canary doesn't show this bug, with and without RAF-Aligned touch input.
- CrOS ToT: disabling PointerEvents and/or RAF-Aligned touch input doesn't fix the problem.

Correction: Windows Canary (57.0.2938.0) *does* show this bug, yikes!!

The touch events are not totally lost, they are getting halted somewhere. All those halted ones are released one-by-one on other events (mouse, keyboard).

Pretty sure it's around input_router.

This happens even for a single finger gesture, just slightly harder to repro.

This is bad enough to be a beta blocker.

Win stable (54.0.2840.99) seems fine.

Running a bisect now on Surface. It narrowed down the range to [417937 (good), 418183 (bad)] so far, but fails to go further. I will give it another try.

Bisect result doesn't point to anything obvious. I double-checked the good & bad "boundary" builds separately, they seem to be labelled correctly:

...
You are probably looking for a change made after 417944 (known good), but no later than 417950 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/38eb7adb1ff6ab5d5151fd47bf251e12da7db0e2..7db14bb2a7dce2cc9e920ac8d6743edb32a83301

rAF aligned input appears to be the issue.

https://chromium.googlesource.com/chromium/src/+/4d208cf0fb7fcad671dcf97c4c9c95af05f1b666

that is just enabled on the waterfall. It has no bearing on the device build.

Ah, right, not a bisect on the waterfall. Yeah, nothing looks suspicious...

Surprisingly, CrOS Beta (55.0.2883.76) doesn't show this bug even though its branch position (423768) is /after/ the bisected range in #6 above.

Confirmed that some field trial is messing up the touch event queue: bisecting with --disable-field-trial-config --enable-benchmarking suppresses the problem throughout the range (between 417944 and 436579).

Apparently there are 3 possible field trials could possibly affect the touch event queue but I can easily repro even with all of them disabled (but field trials enabled):
--disable-features=RafAlighnedTouchInput,PassiveDocumentEventListeners,PassiveEventListenersDueToFling

rkaplow@: Do we have a way to disable a field trial by the hash listed in chrome://version? So that we can disable each through a script & spot the culprit?

Not via hash unfortunately.
I think it might still be best to go through by likelihood of each candidate. I'm hoping you'd quickly find it, there shouldn't be too many that affect performance in this way.

I have an internal way which may help guide the search, I'll ping offline

Is this seen on M56 builds?

My Windows Surface shows the bug for any branch base position after (around) #417950 (Sep 12). So M-56 seems affected.

The first failing Windows build has this "trial hash": bdec89bf-3f4a17df.

For records, the build shows this chrome://version:

Chromium: 55.0.2859.0 (Developer Build) (64-bit)

Revision: 7db14bb2a7dce2cc9e920ac8d6743edb32a83301-refs/heads/master@{#417950}

OS: Windows

JavaScript: V8 5.5.157

Flash:(Disabled)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2859.0 Safari/537.36

Command Line: "c:\users\chromium\appdata\local\temp\bisect_tmpvf4pct\chrome-win32\chrome.exe" --user-data-dir=profile --enable-features=PointerEvent --user-data-dir=bisect-profile --flag-switches-begin --flag-switches-end output.jsbin.com/ludida

Executable Path: c:\users\chromium\appdata\local\temp\bisect_tmpvf4pct\chrome-win32\chrome.exe

Profile Path: c:\users\chromium\appdata\local\temp\bisect_tmpvf4pct\chrome-win32\bisect-profile\Default

Variations:
90757ebb-3f4a17df
b3888d8d-afba0f91
74785582-3f4a17df
ba3f87da-a6404135
a5cb8590-3f4a17df
f049a919-3f4a17df
775ebbd7-3f4a17df
76b48ab8-a2567007
9d315c2-ca7d8d80
5274eb09-3f4a17df
93731dca-3f4a17df
1d3ad72e-3f4a17df
9e243dd-3f4a17df
64cbdfc2-3f4a17df
6b121ae7-3f4a17df
5139837c-3f4a17df
7f8176d9-3f4a17df
f79cb77b-3d47f4f4
b7786474-d93a0620
868bda90-3f4a17df
4ea303a6-3f4a17df
bdec89bf-3f4a17df
9736de91-3f4a17df
b2612322-8a9180b2
ca314179-ea08a3f2
c5073fab-3f4a17df
867c4c68-3f4a17df
d747916f-d747916f
6844d8aa-669a04e0
fe05be5f-4ad60575
828a5926-d8f52f32

Compiler: MSVC 2015

Think I found it:

RafAlignedInput is that hash. Looks like it was added to the field trial test config:
https://codereview.chromium.org/2324803005 (on sept 12).

Unfortunately I did not get a valid experiment name for the "trial hash": bdec89bf-3f4a17df

Here is the finch output for the above hashes.

Output
=======
AutofillProfileCleanup-Enabled
AutomaticTabDiscarding-Enabled_Once_10-gen2
BrowserBlacklist-Enabled
DisallowFetchForDocWrittenScriptsInMainFrame-DocumentWriteScriptBlockGroup
EnableAppContainer-Enabled
EnableMediaRouter-Enabled
ExtensionActionRedesign-Enabled
ExtensionContentVerification-Enforce
IconNTP-Default
InstanceID-Enabled
NetworkQualityEstimator-Enabled
NewProfileManagement-Enabled
NonValidatingReloadOnNormalReload-Enabled
PageRevisitInstrumentation-Enabled
ParseHTMLOnMainThread-Enabled
PassiveDocumentEventListeners-Enabled
PassiveEventListenersDueToFling-Enabled
PasswordGeneration-Disabled
PasswordManagerSettingsMigration-Enable
PreconnectMore-Enabled
QUIC-Enabled
bdec89bf-Enabled
SafeBrowsingIncidentReportingService-Enabled
SettingsEnforcement-enforce_always_with_extensions_and_dse
SiteEngagement-AggressiveAccumulation
SpeculativeLaunchServiceWorker-Enabled
StrictSecureCookies-Enabled
TokenBinding-TokenBinding
TriggeredResetFieldTrial-On
V8CacheStrategiesForCacheStorage-default
WebFontsInterventionV2-Enabled-slow2g

I see a flag in chrome://flags - > Passive Event Listener Override. can you check whether the bug is reproducible by disabling this flag?

Also please provide us with a dump file for debugging the hang.

https://www.chromium.org/for-testers/bug-reporting-guidelines/hanging-tabs

FYI:
Desktop  Beta promotion is planned on Dec -15 and RC @ 4.00 PM PST tomorrow. Please resolve this issue ASAP.

On this CL that feature was split up into 2 features here: https://codereview.chromium.org/2450833003

Which are currently being applied.

Now, I would expect disabling Touch would have fixed it. Except it looks like you had a typo:

--disable-features=RafAlighnedTouchInput,PassiveDocumentEventListeners,PassiveEventListenersDueToFling

Aligned is mispelled.
I'd expect if you disabled RafAlignedTouchInput it would fix it 

CORRECTION 
==========
FYI:
Desktop  Beta promotion is planned on Dec -8 and RC @ 4.00 PM PST tomorrow. Please resolve this issue ASAP.

The reason that trial isn't mapping is because it was the original feature name that was never made into a real trial.

able to reproduce the issue on 56.0.2924.17 /9000.18.0 (Official Build) dev-channel samus

Deleted: Screenshot 2016-12-06 at 12.23.45 PM.png 159 KB

	Screenshot 2016-12-06 at 12.23.45 PM.png 159 KB View Download

This doesn't appear on Beta, seems only dev & canary are affected. I checked 55.0.2883.75.

Dave/Rob: I don't think there's any Beta or Stable is affected. Remove the release-blocker label?

It is a server controlled experiment. It's only pushed to 50/50 dev and canary

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

commit 74b27c5f8ea554abe9e652ecc51530f9e580c147
Author: dtapuska <dtapuska@chromium.org>
Date: Thu Dec 08 21:16:12 2016

Fix issues related to a continuous event getting coalesced with a discrete event.

Touch move events that are non-cancelable are rAF aligned. But a touch
event can get coalesced with a cancelable one which can make a previously
rAF aligned event become a discrete event.

Ack non-cancelable rAF aligned events right away but allow merging of
non-ack required events with ack required events.

BUG= 670039 

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

[modify] https://crrev.com/74b27c5f8ea554abe9e652ecc51530f9e580c147/content/common/input/input_event_dispatch_type.h
[modify] https://crrev.com/74b27c5f8ea554abe9e652ecc51530f9e580c147/content/renderer/input/main_thread_event_queue.cc
[modify] https://crrev.com/74b27c5f8ea554abe9e652ecc51530f9e580c147/content/renderer/input/main_thread_event_queue.h
[modify] https://crrev.com/74b27c5f8ea554abe9e652ecc51530f9e580c147/content/renderer/input/main_thread_event_queue_unittest.cc
[modify] https://crrev.com/74b27c5f8ea554abe9e652ecc51530f9e580c147/content/renderer/input/render_widget_input_handler.cc