Whao, Mobile Safari seems to do exactly what I suggest here!  On http://output.jsbin.com/cepiwe scrolling never opens the pop-up but tapping does.

That's a really strong indication that we can do the same without breaking much.  Also (unlike Safari) Chrome Android has a blocked pop-up notification, so there's an escape hatch.  I'll probably propose that we make this change without bothering with UMA data (given the issues we've seen with buggy ads opening on touchend, it's possible that all the UMA hits would actually be accidental anyway - not sure what we'd do with the numbers).

I think we'll be fixing the 'mayCauseScrollingIfUncanceled' bit to really be 'hasExceededSlopRegion'.  Once we do that, we can probably repurpose it here (what we care about are single-contact touchend events where the touch never exceeded the slop region).

tdresser: sound reasonable to you?

mkwst / jochen: any concerns about changing UGI / pop-up blocker behavior here?

ojan and I he agrees we should try to push forward with this.

If there's no objection, I'll send out some sort of intent for this soon.

Yeah, this sounds pretty reasonable to me.

How should this behave on two finger tap?

The name WebTouchEvent.causesScrollingIfUncanceled confused us before, while working on the pointercancel-on-touch-action bug (crbug.com/567740). I will create a rename-only CL from our existing CL for that bug, to avoid further confusion around the name before we have a working patch for the pointercancel bug.

Two finger tap (or any gesture where the last lifted finger looked like a tap) is a good question.  Ideally I think we wouldn't allow pop-ups for anything but one finger tap, but it's probably not worth adding any code complexity for that.  Since this bit is on TouchEvent, we'll have to define its semantics wrt. multiple fingers, but I don't think the detail matters much for this bug.  Let's discuss in mustaq's CL: https://codereview.chromium.org/1645613007/

esprehn@ points out that we probably need to be careful not to break cases like an iOS-style slider-switch which, when activated, requests a permission (like geolocation).  That's not a tap, but it's clearly an explicit user interaction.  I'll test Safari to see if that sort of thing works.

We suggest instead this possible algorithm:
 - don't take a UGI on touchstart/touchmove
 - on touchend, if a touch-scroll did not occur (i.e. the TouchEvent is cancelable) AND the touchend occurred on top of the same frame that the touchstart occurred, then take a UGI.

The idea here is that if the user moves their finger and the page doesn't scroll (because the event was canceled), but they lift outside the frame, this represents a failed scroll not an attempt to interact with the frame.

esprehn@ also says the pop-up blocker algorithm is defined precisely by HTML5.  I haven't been able to find that yet.

Pop-up blocker spec text is https://html.spec.whatwg.org/multipage/browsers.html#allowed-to-show-a-popup

It currently says that pop-ups are allowed from trusted "mouseup" and "click" event listeners, but says nothing about "touchend" or "pointerup".  I filed https://github.com/whatwg/html/issues/599 to track expanding this text for touch.

Both Safari and Chrome today allow geolocation prompts on a swipe: https://output.jsbin.com/cepiwe

I'm going to try to get something into M-50, even if we start with something simpler / lower risk.  Eg. how about we take a UGI on touchend if the touch is targetted at the main frame, or it represents a tap.  Cases like "swipe to enable GPS" should be rare anywhere, nevermind in an iframe.
 
I'm out until 2/17, so this may slip to M-51.

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

commit 620be1f0cde37e56b8f8eb9e238e3d28b6471fc7
Author: mustaq <mustaq@chromium.org>
Date: Mon Feb 08 22:47:46 2016

Redefined the bit WebTouchEvent.causesScrollingIfUncanceled.

The "causesScrollingIfUncanceled" name is confusing because this bit
essentially means that a touchmove has exceeded the touch slop region.
A touchmove with this bit set doesn't necessarily cause scrolling,
even when uncanceled, e.g. when the touch sequence started on a node
with "touch-action:none".

This CL redefines the bit: this bit remains unset as long as the
touch-point is within the slop region, and is set after the first
touchmove beyond the slop region.

The bit is set by gesture-provider, and currently used in two places:
for touchmove slop suppression and for suppressing PointerEvent firing
for events that cause panning/zooming. This new definition was chosen
to be useful for both the current slop suppression and to enable us to
detect tap-like touchend events from blink (eg. for crbug.com/582140).
We are fixing the PointerEvent use case through crbug.com/567740.

BUG= 582140 , 567740 

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

Cr-Commit-Position: refs/heads/master@{#374204}

[modify] http://crrev.com/620be1f0cde37e56b8f8eb9e238e3d28b6471fc7/blimp/client/feature/compositor/blimp_input_manager.cc
[modify] http://crrev.com/620be1f0cde37e56b8f8eb9e238e3d28b6471fc7/components/html_viewer/touch_handler.cc
[modify] http://crrev.com/620be1f0cde37e56b8f8eb9e238e3d28b6471fc7/components/test_runner/event_sender.cc
[modify] http://crrev.com/620be1f0cde37e56b8f8eb9e238e3d28b6471fc7/content/browser/renderer_host/input/touch_emulator.cc
[modify] http://crrev.com/620be1f0cde37e56b8f8eb9e238e3d28b6471fc7/content/browser/renderer_host/input/touch_event_queue.cc
[modify] http://crrev.com/620be1f0cde37e56b8f8eb9e238e3d28b6471fc7/content/browser/renderer_host/input/touch_event_queue_unittest.cc
[modify] http://crrev.com/620be1f0cde37e56b8f8eb9e238e3d28b6471fc7/content/browser/renderer_host/render_widget_host_view_android.cc
[modify] http://crrev.com/620be1f0cde37e56b8f8eb9e238e3d28b6471fc7/content/common/input/synthetic_web_input_event_builders.cc
[modify] http://crrev.com/620be1f0cde37e56b8f8eb9e238e3d28b6471fc7/content/common/input/web_input_event_traits.cc
[modify] http://crrev.com/620be1f0cde37e56b8f8eb9e238e3d28b6471fc7/third_party/WebKit/Source/web/WebInputEventConversion.cpp
[modify] http://crrev.com/620be1f0cde37e56b8f8eb9e238e3d28b6471fc7/third_party/WebKit/public/web/WebInputEvent.h
[modify] http://crrev.com/620be1f0cde37e56b8f8eb9e238e3d28b6471fc7/ui/aura/window_event_dispatcher_unittest.cc
[modify] http://crrev.com/620be1f0cde37e56b8f8eb9e238e3d28b6471fc7/ui/events/blink/blink_event_util.cc
[modify] http://crrev.com/620be1f0cde37e56b8f8eb9e238e3d28b6471fc7/ui/events/gesture_detection/filtered_gesture_provider.cc
[modify] http://crrev.com/620be1f0cde37e56b8f8eb9e238e3d28b6471fc7/ui/events/gesture_detection/filtered_gesture_provider.h
[modify] http://crrev.com/620be1f0cde37e56b8f8eb9e238e3d28b6471fc7/ui/events/gesture_detection/filtered_gesture_provider_unittest.cc
[modify] http://crrev.com/620be1f0cde37e56b8f8eb9e238e3d28b6471fc7/ui/events/gestures/gesture_provider_aura.cc

Intervention doc: https://docs.google.com/document/d/1oF1T3O7_E4t1PYHV6gyCwHxOi3ystm0eSL5xZu7nvOg/edit#

Initial WIP CL for the measurement/warning piece: https://codereview.chromium.org/1799253002/

Added to WICG interventions list here: https://github.com/WICG/interventions/issues/13

Chromestatus entry: https://www.chromestatus.com/feature/5649871251963904

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

commit fb38d26a84cfab930dfb53a2f338534aa0ef3100
Author: rbyers <rbyers@chromium.org>
Date: Thu Apr 07 19:07:27 2016

Stricter user gestures for touch - measure and warn

Add UserGestureIndicator infrastructure for being notified when the state of a UserGestureIndicator is used.  Use this infrastructure to get an idea of the potential impact of the "stricter user gestures for touch" intervention, and warn developers about it.

See https://docs.google.com/document/d/1oF1T3O7_E4t1PYHV6gyCwHxOi3ystm0eSL5xZu7nvOg/edit#

BUG= 582140 

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

Cr-Commit-Position: refs/heads/master@{#385826}

[modify] https://crrev.com/fb38d26a84cfab930dfb53a2f338534aa0ef3100/third_party/WebKit/Source/core/dom/Fullscreen.cpp
[modify] https://crrev.com/fb38d26a84cfab930dfb53a2f338534aa0ef3100/third_party/WebKit/Source/core/editing/commands/EditorCommand.cpp
[modify] https://crrev.com/fb38d26a84cfab930dfb53a2f338534aa0ef3100/third_party/WebKit/Source/core/frame/Deprecation.cpp
[modify] https://crrev.com/fb38d26a84cfab930dfb53a2f338534aa0ef3100/third_party/WebKit/Source/core/frame/Deprecation.h
[modify] https://crrev.com/fb38d26a84cfab930dfb53a2f338534aa0ef3100/third_party/WebKit/Source/core/frame/LocalDOMWindow.cpp
[modify] https://crrev.com/fb38d26a84cfab930dfb53a2f338534aa0ef3100/third_party/WebKit/Source/core/frame/UseCounter.h
[modify] https://crrev.com/fb38d26a84cfab930dfb53a2f338534aa0ef3100/third_party/WebKit/Source/core/html/AutoplayExperimentHelper.cpp
[modify] https://crrev.com/fb38d26a84cfab930dfb53a2f338534aa0ef3100/third_party/WebKit/Source/core/html/HTMLFormElement.cpp
[modify] https://crrev.com/fb38d26a84cfab930dfb53a2f338534aa0ef3100/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp
[modify] https://crrev.com/fb38d26a84cfab930dfb53a2f338534aa0ef3100/third_party/WebKit/Source/core/html/forms/ColorInputType.cpp
[modify] https://crrev.com/fb38d26a84cfab930dfb53a2f338534aa0ef3100/third_party/WebKit/Source/core/html/forms/FileInputType.cpp
[modify] https://crrev.com/fb38d26a84cfab930dfb53a2f338534aa0ef3100/third_party/WebKit/Source/core/input/EventHandler.cpp
[modify] https://crrev.com/fb38d26a84cfab930dfb53a2f338534aa0ef3100/third_party/WebKit/Source/core/input/EventHandler.h
[modify] https://crrev.com/fb38d26a84cfab930dfb53a2f338534aa0ef3100/third_party/WebKit/Source/core/loader/FrameLoader.cpp
[modify] https://crrev.com/fb38d26a84cfab930dfb53a2f338534aa0ef3100/third_party/WebKit/Source/core/loader/NavigationScheduler.cpp
[modify] https://crrev.com/fb38d26a84cfab930dfb53a2f338534aa0ef3100/third_party/WebKit/Source/modules/presentation/PresentationRequest.cpp
[modify] https://crrev.com/fb38d26a84cfab930dfb53a2f338534aa0ef3100/third_party/WebKit/Source/modules/remoteplayback/RemotePlayback.cpp
[modify] https://crrev.com/fb38d26a84cfab930dfb53a2f338534aa0ef3100/third_party/WebKit/Source/platform/UserGestureIndicator.cpp
[modify] https://crrev.com/fb38d26a84cfab930dfb53a2f338534aa0ef3100/third_party/WebKit/Source/platform/UserGestureIndicator.h
[modify] https://crrev.com/fb38d26a84cfab930dfb53a2f338534aa0ef3100/third_party/WebKit/Source/platform/UserGestureIndicatorTest.cpp
[modify] https://crrev.com/fb38d26a84cfab930dfb53a2f338534aa0ef3100/tools/metrics/histograms/histograms.xml

Measurement shipped in M51, hoping to have enough data to pro-actively justify shipping this change in M52.

Initial dev-channel data in M51 indicates that ~0.05% of page views include a touch-drag user gesture getting used in cross-origin iframes (the case we want to break).  This volume (or even a little bigger) seems consistent with the anecdotes about ads opening incorrectly.  I'll double check the data once Chrome 51 hits beta on Android, but assuming it stays about this level I'll argue for removing this capability in M52.

The non-cross-origin-iframe case is about 5x more common, so it's unclear what's going on there.  I plan to continue to monitor but (for now) not deprecate this scenario.

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

commit 97a365a7a2fef83461694833288a0f8d18769404
Author: dtapuska <dtapuska@chromium.org>
Date: Fri Apr 29 19:29:53 2016

Fix bogus warning message for touch drag gesture used cross origin.

The chromestatus URI prefix was added twice. willBeRemoved does
a sprintf with the URI on the front.

BUG= 582140 

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

[modify] https://crrev.com/97a365a7a2fef83461694833288a0f8d18769404/third_party/WebKit/Source/core/frame/Deprecation.cpp

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

commit 709aa1e9ea8995de6c4a89edc2f7009122569814
Author: rbyers <rbyers@chromium.org>
Date: Thu May 12 04:44:06 2016

Remove user gestures on touches other than tap in cross-origin iframes

Also replaces our tests for user gestures during touch events.

See https://docs.google.com/document/d/1oF1T3O7_E4t1PYHV6gyCwHxOi3ystm0eSL5xZu7nvOg/edit#heading=h.qq59ev3u8fba

Intent-to-remove: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/piK75azdN5o

BUG= 582140 

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

[modify] https://crrev.com/709aa1e9ea8995de6c4a89edc2f7009122569814/components/test_runner/event_sender.cc
[modify] https://crrev.com/709aa1e9ea8995de6c4a89edc2f7009122569814/components/test_runner/event_sender.h
[delete] https://crrev.com/622ba77c6aab35b6a8a367fa8be99a03ae8e0480/third_party/WebKit/LayoutTests/fast/events/popup-allowed-from-touch-only-once-expected.txt
[delete] https://crrev.com/622ba77c6aab35b6a8a367fa8be99a03ae8e0480/third_party/WebKit/LayoutTests/fast/events/popup-allowed-from-touch-only-once.html
[add] https://crrev.com/709aa1e9ea8995de6c4a89edc2f7009122569814/third_party/WebKit/LayoutTests/fast/events/touch/resources/touch-user-gesture-frame.html
[add] https://crrev.com/709aa1e9ea8995de6c4a89edc2f7009122569814/third_party/WebKit/LayoutTests/fast/events/touch/touch-user-gesture-cross-origin-expected.txt
[add] https://crrev.com/709aa1e9ea8995de6c4a89edc2f7009122569814/third_party/WebKit/LayoutTests/fast/events/touch/touch-user-gesture-cross-origin.html
[add] https://crrev.com/709aa1e9ea8995de6c4a89edc2f7009122569814/third_party/WebKit/LayoutTests/fast/events/touch/touch-user-gesture-expected.txt
[add] https://crrev.com/709aa1e9ea8995de6c4a89edc2f7009122569814/third_party/WebKit/LayoutTests/fast/events/touch/touch-user-gesture.html
[modify] https://crrev.com/709aa1e9ea8995de6c4a89edc2f7009122569814/third_party/WebKit/Source/core/frame/Deprecation.cpp
[modify] https://crrev.com/709aa1e9ea8995de6c4a89edc2f7009122569814/third_party/WebKit/Source/core/frame/UseCounter.h
[modify] https://crrev.com/709aa1e9ea8995de6c4a89edc2f7009122569814/third_party/WebKit/Source/core/input/EventHandler.cpp
[modify] https://crrev.com/709aa1e9ea8995de6c4a89edc2f7009122569814/third_party/WebKit/Source/core/input/TouchEventManager.cpp

This has landed.  Issue 572319 tracks additional work.

Issue 572319 has been merged into this issue.

I have a custom video control bar, the progress bar can allow the user to seek the video. For performance and less awkward user experience (not playing the video while the user is scrubbing the timeline), I pause() the video on touchstart and then play() the video again on touchend().

However I am getting this warning and this is appears to be confused with a "scroll" gesture, which it is most definitely not.

Warning message in DevTools console: "Performing operations that require explicit user interaction on touchend events that occur as part of a scroll is deprecated and will be removed in M54, around October 2016. See https://www.chromestatus.com/features/5649871251963904 for more details."

The warning linked me to the feature detail and this chromium issue.

nexiim@, are you calling preventDefault() on the touch events?

Do you have an example we can play with?

There is a removal warning in Deprecation.cpp for this in M56 (branching in 2 weeks). Are we still on track for removal in M56?

#20: Yes I think so, working on landing the CL now - issue 611981

Seeing the deprecation warning for this currently - am a little concerned because I am trying to pause audio on a mousedown/touch event which is explicit and pausing whould be allowed.

jimmy.thompson, can you point us to a page you're seeing a problem on? Pausing audio should be unaffected by this change. If we're breaking pausing of audio, then we'd definitely like to know and fix it. :)