New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 625228 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Buried. Ping if important.
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

Disallow navigation on touch events in sandboxed iframes

Project Member Reported by rbyers@chromium.org, Jul 1 2016

Issue description

Many ads are activated in response to touch events.  Often the ad does this incorrectly resulting in a poor user experience and bad conversion metrics, eg:
 - triggering navigation on touchstart or touchend even after a scroll (mitigated by  issue 582140 )
 - navigating when the user taps to stop a fling (don't get "tap suppression")
 - navigating when the user accidentally taps right after the frame changed positions (could be addressed for click in issue 603193)

To enable a solution to all these issues, ads should be navigating only in response to "click" events (with click-delay elimination as described in https://developers.google.com/web/updates/2013/12/300ms-tap-delay-gone-away?hl=en).  But there's no way for an ad network to enforce this.

Perhaps sandboxed iframes shouldn't, by default, be permitted to trigger a navigation outside of event handlers for (trusted) click events?  Or, worst case, there could be an opt-in option for this.

mkwst WDYT?

See related  issue 611982 .
 
Summary: Disallow navigation on touch events in sandboxed iframes (was: Enable opt-out of navigation on touch events in sandboxed iframes)
Re "But there's no way for an ad network to enforce this", should this be part of the Content Feature Policy [1] ?


[1]: https://github.com/WICG/feature-policy
Cc: igrigo...@chromium.org
Status: Assigned (was: Unconfirmed)

Comment 5 by est...@chromium.org, Nov 10 2017

Labels: Hotlist-EnamelAndFriendsFixIt

Comment 6 by rbyers@chromium.org, Nov 27 2017

Cc: iclell...@chromium.org
Components: Blink>FeaturePolicy
We could totally start with a opt-in feature policy for this, and based on successful adoption of that consider switching the default in some cases.
+iclelland to add to his list.

Comment 7 by rbyers@chromium.org, Nov 27 2017

Cc: mustaq@chromium.org
And perhaps we could get much of the benefit by narrowing this just to "activation" like the existing pop-up blocking code.  I.e. a touchend that occurred without a scroll would still count as "activation".

Comment 8 by est...@chromium.org, Feb 18 2018

Labels: -Hotlist-EnamelAndFriendsFixIt

Comment 9 by ojan@chromium.org, May 8 2018

Cc: -ojan@chromium.org

Sign in to add a comment