Proposed intervention: User gestures for touch

8 views
Skip to first unread message

Rick Byers

unread,
Mar 11, 2016, 5:29:26 PM3/11/16
to intervention-dev, Elliott Sprehn, input-dev, Jochen Eisinger
Chromium uses UserGestureIndicators to identify when we believe a user is actively trying to interact with a web page, and restricts certain sensitive operations (pop-ups, fullscreen, geolocation requests, etc.) to being permitted only during such a user gesture.  I filed this intervention to track getting our current UserGestureIndicator behavior written up as a proper intervention.  I don't know all the history here, and how it relates to existing specs and behavior in other browsers.

This behavior has never been fully thought through for touch input, and we have a high-profile issue where some ads are activating on the touchend from a touch scroll in Chrome (where Safari just ignores such calls to window.open).

I'm proposing an intervention to tighten up our user gesture behavior for touch, at least (for now) in the case of cross origin iframes.  Basically only touch events which represent a tap should be considered as user gestures.

Feedback (here or in the doc) is appreciated.  Is there guidance written somewhere on "intent to intervene" threads?  I'd like to send one (or maybe it's just a deprecate-and-remove thread) out soon, starting with adding use counters and deprecation messages.  I've got a prototype CL for this which I'll share soon after I've tested it some more.

Thanks,
   Rick


Kenji Baheux

unread,
Mar 16, 2016, 3:38:46 AM3/16/16
to Rick Byers, intervention-dev, Elliott Sprehn, input-dev, Jochen Eisinger
Thanks for reaching out.

 
 Is there guidance written somewhere on "intent to intervene" threads?  I'd like to send one (or maybe it's just a deprecate-and-remove thread)

The guidance so far has been to use the existing intent to * templates. The only specific bits I can think of are:
  1. getting the incentives right and/or minimizing risk (e.g. avoid what happened after we turned off autoplay; provide an escape hatch if the intervention might break legit cases).
  2. always have a finch flag for the intervention to easily turn it off in case we find out compat issues.

 

--
You received this message because you are subscribed to the Google Groups "intervention-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intervention-d...@chromium.org.
To post to this group, send email to interven...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/CAFUtAY_9w9YSVFG%3Dj1pUsR6Pr%2BY7Ya-LSogpRo%3Dgc1VkuYtCbQ%40mail.gmail.com.

Jochen Eisinger

unread,
Mar 16, 2016, 3:49:24 AM3/16/16
to Kenji Baheux, Rick Byers, intervention-dev, Elliott Sprehn, input-dev
A similar intervention idea I had was to restrict cross origin navigations of the main frame via setting the document.location to require a user gesture. This would thwart a common pattern of pop-unders where you open yourself in a new tab (requiring a user gesture) and then navigate your old copy to an ad (currently not requiring a user gesture).

A second thing, on mobile, we remember for each network request whether it was created while an active user gesture indicator was on the stack. When the network response then comes in, we allow firing intents in the javascript callback of the XHR/fetch (but not new tabs). That was added to support ads where a click results in a phone call intent being made - the network request creates a temporary phone number. Not sure how good our test coverage for this is.

best
-jochen
Reply all
Reply to author
Forward
0 new messages