Intent to Remove: user gesture on touch scroll

[Rick Byers]

Primary eng (and PM) emails

rby...@chromium.org

Link to “Intent to Deprecate” thread

Here

Summary

Only consider a touch event a "user gesture" when it's the touchend associated with a tap.

WICG Interventions Issue

Motivation

We've seen multiple examples of poorly written / malicious ads which trigger navigation for touch scrolls (either on touchstart or all touchend events). If a 'wheel' event can't open a pop-up, then really touch scrolling shouldn't either. The previous change was the minimal thing necessary to stop the worst cases (cross-origin iframes), but now I'd like to attempt to make this more consistent / more thorough.

Compatibility Risk

There is a non-trivial risk that this will break some scenarios - media not playing on touch, pop-ups not opening on touch. However it's unclear what fraction of that is desired vs. undesired behavior. Safari already silently fails to open pop-ups in all of these scenarios, so we shouldn't be breaking anything that works in Safari.

Usage information from UseCounter

I've attempted to quantify the risk by measuring when a user gesture is used from within a touchstart, touchmove or (non-tap) touchend handler. Results on Android Stable (as % of PageVisits) are as follows:

TouchStartUserGestureUtilized: 0.16%

TouchMoveUserGestureUtilized: 0.015%

TouchEndDuringScrollUserGestureUtilized: 0.05%

All of these numbers are higher than I hoped and are worrying. I've tried to look at how they could be a measurement error, but haven't come up with anything wrong. Ideally I'd have some way to find specific examples to investigate, but I can't come up with any practical way to find them (hard to simulate real user input, etc.). My gut instinct is that since Mobile Safari already doesn't support these cases, this is going to be a mix of intentional abuse, subtle websites bugs whose impact isn't user visible, and some small amount of real breakage in Chrome-specific code.

After sitting on this for a few months, thinking through different options and talking to a few folks, I think the best path forward is to just try to ship this. The breakage is still bounded to a low number, and Safari compatibility means this is potentially a net predictability improvement. If more than one real-world website is discovered to be broken in a non-trivial way during beta, I'll revert and re-evaluate.

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=611981

Entry on the feature dashboard

https://www.chromestatus.com/features/5649871251963904

[Jochen Eisinger]

lgtm1

[Elliott Sprehn]

Does this break light switch widgets? I totally support not granting a gesture if the page actually scrolled, but if the author has touch-action set and you toggle a switch that should trigger a gesture. If we don't you produce a strange situation where tapping the switch does the action (ex. Plays audio) but sliding it doesn't. It's possible the UX is worse here in Safari, but I don't think we should copy their behavior if it means limiting a popular UX paradigm like this.

[Rick Byers]

No, my plan was not to break light switch widgets that trigger on touchend (regardless of whether a scroll occurred or not).  I.e. the change I want to make is described as the "new proposed intervention" in this doc, but I was sloppy in my summary of it below (thanks for pointing that out).  Re-written inline.

On Wed, Oct 12, 2016 at 4:15 AM, Elliott Sprehn <esp...@google.com> wrote:

Does this break light switch widgets? I totally support not granting a gesture if the page actually scrolled, but if the author has touch-action set and you toggle a switch that should trigger a gesture. If we don't you produce a strange situation where tapping the switch does the action (ex. Plays audio) but sliding it doesn't. It's possible the UX is worse here in Safari, but I don't think we should copy their behavior if it means limiting a popular UX paradigm like this.

On Oct 11, 2016 7:34 PM, "Rick Byers" <rby...@chromium.org> wrote:

Primary eng (and PM) emails

rby...@chromium.org

Link to “Intent to Deprecate” thread

Here

Summary

Only consider a touch event a "user gesture" when it's the touchend associated with a tap.

Correction: Only consider a touch event a user gesture when it's a touchend not associated with a scroll (i.e. was a tap, a drag where scrolling had been disabled by touch-action or canceling of prior touch events, or some multi-finger gesture which similarly did not trigger scrolling or zooming).

[Elliott Sprehn]

Oh great! Glad I was just confused here. :)

[Chris Harrelson]

LGTM2

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Steve Kobes]

LGTM overall.

On Tue, Oct 11, 2016 at 7:33 PM, Rick Byers <rby...@chromium.org> wrote:

We've seen multiple examples of poorly written / malicious ads which trigger navigation for touch scrolls (either on touchstart or all touchend events).

I think navigation in general doesn't require a user gesture.  Are there plans to change that, or do we only care about the popups?

[Rick Byers]

There are separate interventions to further restrict when navigation can happen (eg. see japhet@'s most recent intent and others on the tracking sheet) but it's complex and full of challenging web compat tradeoffs.

[Philip Jägenstedt]

Is this still waiting for 3xLGTM? LGTM3!

[Rick Byers]

Thank you!

Yes I figured (having been swamped myself and behind on intents) I had no right to complain about the delay ;-)

Rick

[Joe Medley]

Rick,

Do you think maybe this deserves its own dashboard item?

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Rick Byers]

Sorry for the delay Joe, I finally got back to this.  Yes, a dedicated entry (rather than combining first step) is probably a good idea, thanks - done.

The change for this has now landed.

[anna.e...@gmail.com]

Hi,

Because of removing the touch gestures of touch start and touch end, on Chrome browser and Windows 10, the stylus does not work and because of which our web application of whiteboard is non functional. Please help us resolve this issue ASAP

Regards,

Annarao Kulkarni

[Dave Tapuska]

Annarao,

Please open a new issue cc'ng me and tagging it as Blink>Input. We can discuss the issue that you are seeing there. From your email it isn't clear what version you are using and what website. There were some recent (Chrome 62) changes with respect to stylus and I'm wondering if you are confusing those changes with this user gesture behaviour. It is best we discuss this on a bug.

dave.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c35dbe55-420b-46df-aa29-a280f4ffe2e3%40chromium.org.