I was thinking of doing this via dev tools as part of my intervention mechanisms that I was planning in my OKRs for Q2. But a setting also seems good.

Definitely "make all touch listeners on this page passive" is a good devtools feature.

Some sort of flag will be useful for testing too, but we need to be cautious that a number of websites will be broken by making all their listeners passive.  If we add a flag for this, please make sure it doesn't cause the implicit touch-action listeners to become passive (that way sites annotated correctly with touch-action will work correctly, though still have potential perf issues until we fix 318381)

After playing with such a flag, I agree that at LEAST the "force all document-wide touch listeners to be passive" option would be really useful - eg. in demonstrating the power of the feature and potential for an intervention here.  Aim to get this into M52?

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

commit f65650b0471dfd3d5fda67ae634a986148ad2d3e
Author: dtapuska <dtapuska@chromium.org>
Date: Fri May 13 17:21:34 2016

Add runtime setting to force passive event listeners.

Add the ability to set the default value for the 'passive' field
in AddEventListenerOptions.

The value can take on 4 values; 'false', 'true', 'documentonlytrue',
'forcetrue'. It can be set from the command line or by adjusting
the chrome://flags.

BUG= 599611 

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

[modify] https://crrev.com/f65650b0471dfd3d5fda67ae634a986148ad2d3e/chrome/app/generated_resources.grd
[modify] https://crrev.com/f65650b0471dfd3d5fda67ae634a986148ad2d3e/chrome/browser/about_flags.cc
[modify] https://crrev.com/f65650b0471dfd3d5fda67ae634a986148ad2d3e/content/browser/renderer_host/render_process_host_impl.cc
[modify] https://crrev.com/f65650b0471dfd3d5fda67ae634a986148ad2d3e/content/public/common/content_switches.cc
[modify] https://crrev.com/f65650b0471dfd3d5fda67ae634a986148ad2d3e/content/public/common/content_switches.h
[modify] https://crrev.com/f65650b0471dfd3d5fda67ae634a986148ad2d3e/content/renderer/render_view_impl.cc
[add] https://crrev.com/f65650b0471dfd3d5fda67ae634a986148ad2d3e/third_party/WebKit/Source/core/events/AddEventListenerOptionsDefaults.h
[modify] https://crrev.com/f65650b0471dfd3d5fda67ae634a986148ad2d3e/third_party/WebKit/Source/core/events/EventTarget.cpp
[modify] https://crrev.com/f65650b0471dfd3d5fda67ae634a986148ad2d3e/third_party/WebKit/Source/core/events/EventTarget.h
[modify] https://crrev.com/f65650b0471dfd3d5fda67ae634a986148ad2d3e/third_party/WebKit/Source/core/frame/Settings.h
[modify] https://crrev.com/f65650b0471dfd3d5fda67ae634a986148ad2d3e/third_party/WebKit/Source/core/frame/Settings.in
[modify] https://crrev.com/f65650b0471dfd3d5fda67ae634a986148ad2d3e/third_party/WebKit/Source/web/AssertMatchingEnums.cpp
[modify] https://crrev.com/f65650b0471dfd3d5fda67ae634a986148ad2d3e/third_party/WebKit/Source/web/WebSettingsImpl.cpp
[modify] https://crrev.com/f65650b0471dfd3d5fda67ae634a986148ad2d3e/third_party/WebKit/Source/web/WebSettingsImpl.h
[modify] https://crrev.com/f65650b0471dfd3d5fda67ae634a986148ad2d3e/third_party/WebKit/public/web/WebSettings.h
[modify] https://crrev.com/f65650b0471dfd3d5fda67ae634a986148ad2d3e/tools/metrics/histograms/histograms.xml

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

commit 3d0d596af9ff7592a0b6fe390e54491349950175
Author: dtapuska <dtapuska@chromium.org>
Date: Fri May 13 20:55:35 2016

Fix actions.xml missing about flags field for passive listeners.

In change https://codereview.chromium.org/1965493002/ actions.xml
was not updated. Correctly update this xml file.

BUG= 599611 

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

[modify] https://crrev.com/3d0d596af9ff7592a0b6fe390e54491349950175/tools/metrics/actions/actions.xml

This is now in Canary builds (eg. 52.0.2738.0) and feels great to me!  I encourage people to set chrome://flags#passive-listener-default to "Document level true" for daily browsing and see if they find any websites that break (the other options will definitely break scenarios like carousels etc. but the impact may often be subtle in practice).

First example of breakage: the AMP carousel.  When tapping on a link it appears to do a double-navigate.  First opening the AMP carousel, then navigating directly to the actual target page.  GWS amp carousel is definitely using event delegation (all the carousel's touch handlers are on html/document).

One guess for this sort of issue is that the carousel calls preventDefault on touchstart but not touchend.  Then when you tap on an item with the touchstart listener forced passive, it gets both the touchend and (unexpectedly) the click event.  That can't be the case here though because vertical scrolling still works - so they're not canceling touchstart events.  I'm having a heck of a time getting making sense out of what I'm seeing in devtools (something must be broken - not seeing the touchmove listeners at all, not seeing any calls to preventDefault).

Sounds good to investigate that and see if we can find a way to finesse the intervention to avoid that class of breakage.

Regardless, GWS and AMP should definitely change on their end to use passive event listeners, since that's a big performance win.  Matle, is that on your roadmap?  (Some context in case you haven't heard of this new API: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/8hsz3bOFBpY/kUHDGmTPDQAJ )

We can try. This API is sooo hard to use, due to being not backwards compatible with respect to capture.

malteuble@ - can you give more detail on what makes this API difficult to use? Are you just having issues with feature detection?

See https://github.com/WICG/EventListenerOptions/blob/gh-pages/explainer.md#user-content-feature-detection for one approach to performing feature detection.

The feature detection is easy enough, but it is annoying that, unless one is fine with monkey patching host-prototypes, one can no longer directly use the DOM APIs.

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

commit b38d8cc6524ed76a371abb851f97e534aab04926
Author: dtapuska <dtapuska@chromium.org>
Date: Tue May 31 17:38:14 2016

Fix runtime setting forcing passive event listeners to scroll blocking events.

Previously the runtime settings would apply to all events; make it
restricted to scroll blocking events.

Also adjust the blockedEventsWarning threshold to use this same event
type (it was previously reporting touchend as well; which it shouldn't
have)

BUG= 599611 

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

[modify] https://crrev.com/b38d8cc6524ed76a371abb851f97e534aab04926/third_party/WebKit/LayoutTests/inspector/input-event-warning-expected.txt
[modify] https://crrev.com/b38d8cc6524ed76a371abb851f97e534aab04926/third_party/WebKit/LayoutTests/inspector/input-event-warning.html
[modify] https://crrev.com/b38d8cc6524ed76a371abb851f97e534aab04926/third_party/WebKit/Source/core/events/EventTarget.cpp
[modify] https://crrev.com/b38d8cc6524ed76a371abb851f97e534aab04926/third_party/WebKit/Source/core/events/EventTarget.h

Moving this nonessential bug to the next milestone.

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

Your change meets the bar and is auto-approved for M52 (branch: 2743)

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

commit 244b55720606f9fccf929f4d3146972426f56e19
Author: Dave Tapuska <dtapuska@chromium.org>
Date: Fri Jun 03 13:17:34 2016

Fix runtime setting forcing passive event listeners to scroll blocking events.

Previously the runtime settings would apply to all events; make it
restricted to scroll blocking events.

Also adjust the blockedEventsWarning threshold to use this same event
type (it was previously reporting touchend as well; which it shouldn't
have)

BUG= 599611 

Review-Url: https://codereview.chromium.org/2024913002
Cr-Commit-Position: refs/heads/master@{#396855}
(cherry picked from commit b38d8cc6524ed76a371abb851f97e534aab04926)

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

Cr-Commit-Position: refs/branch-heads/2743@{#202}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/244b55720606f9fccf929f4d3146972426f56e19/third_party/WebKit/Source/core/events/EventTarget.cpp
[modify] https://crrev.com/244b55720606f9fccf929f4d3146972426f56e19/third_party/WebKit/Source/core/events/EventTarget.h