New issue
Advanced search Search tips
Starred by 16 users

Issue metadata

Status: Duplicate
Merged: issue 582140
Closed: Jun 2016
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocked on:
issue 582140
issue 611981
issue 611982

issue 576714

Sign in to add a comment

Issue 572319: Scroll gesture interpreted as click - opens ads inadvertently

Reported by, Dec 26 2015

Issue description

Example URL:

Steps to reproduce the problem:
1. Open a web site using Google ads
2. scroll around
3. try to hit an ad using the scroll gesture (and keep scrolling)

What is the expected behavior?
ad must not open

What went wrong?
ad opens inadvertently quite often because scroll gesture is frequently interpreted as a click

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? N/A 

Chrome version: 47.0.2526.83  Channel: stable
OS Version: 6.0.1
Flash Version: 

This is happening for many months now on different devices and causes unwanted popups and page navigations all the time.
I think this started with the introduction of swiffy ads.

Comment 1 Deleted

Comment 2 by, Dec 26 2015

I recorded a short demonstration video:

First click starts at 0:13, there are several unwanted activations in this video

Comment 3 by, Dec 28 2015

Labels: -Cr-Blink Cr-Blink-Input

Comment 4 by, Jan 7 2016

Labels: Hotlist-Input-Dev
I am not able to reproduce this issue using same version of chrome on Android 6.0.1 Nexus 5X.
Here is the article that I was testing based on what was in the video:

Can you confirm that the issue still exists for you?

Comment 5 by, Jan 7 2016

Yes, it still happens occasionally.

It really depends on the ads, some do not seem to trigger this at all, some others trigger it quite easiy (not sure but may be related how they are animated).
Also, sometimes I can trigger it easily, and then I fail to reproduce it on the same ad.

Unfortunately, due to the nature of ads being very dynamic, it seems impossible to "save" a test case (I tried saving a complete website using Chrome Desktio, but ads are not loading...)
I assume that you are seeing other ads than me, either they do not trigger it easily, or you have a slightly different style of swiping.

Btw., it seems that I am not the only person seeing this, I have read occasional complaints of other user on G+, blog comments etc ...)
Also, it is not related to "" - this was just an example. I also noticed it quite often on other sites, like etc.

Comment 6 by, Jan 7 2016

My version of this issue is that some pages have performance issue.
On those pages you actually need to touch and stay for a split second for your finger to be recognized then you can start scrolling.
If one slides his/her finger as quick as usual attempting to scroll, the slide would be recognized as a single touch due to the delay.

Comment 7 by, Jan 8 2016

@ #6

it also happens for me when performance i smooth, at least it looks smooth.

Comment 8 by, Jan 11 2016

Status: Available

Comment 9 by, Jan 12 2016

This page also causes this issue:

I'm unsure if I'm experiencing the same issue as when I tap on the ad and try to scroll, the page does not move. When I lift my finger, the ad is opened. This issue is not reliably reproducible as it does not happen with every ad even when refreshing the same page.

Chrome beta 48.2564.71

Comment 10 by, Jan 14 2016

This happens to me consistently with a Google Store Nexus 5X ad (screenshot attached -- seen on multiple websites but that is from  I can initiate a scroll gesture from anywhere except the ad (including the grey bars on the left and right of the ad).  When I attempt to initiate a scroll gesture from the ad there is no scrolling at all; instead, it registers an ad "click", opens a new tab, and loads "<query_params>".

Farther down the page where the screenshot was taken is another ad, this one for Amazon Prime Now.  I can initiate a scroll gesture anywhere on that ad (even on the "Install" button).  So only certain ads have this scroll-to-click behavior.
193 KB View Download

Comment 11 by, Jan 15 2016

+klobag +tedchoc

Comment 12 by, Jan 15 2016


Comment 13 by, Jan 15 2016

Corresponding internal bug b/26505568

Comment 14 by, Jan 15 2016


Comment 15 by, Jan 15 2016

Blocking: chromium:576714

Comment 16 by, Jan 15 2016

This seems to be an issue with the Ad scripts rather than Chrome itself. In fact, I can reproduce the same behaviour in Mobile Safari.

The ad appears to be adding a  touchend handler in which it opens the target URL. Treating touchend instead of click is why scroll gesture is broken. Here is a simple example I created based on what the ad is doing:

Comment 17 by, Jan 15 2016

OP here...

I think that this is a different issue than what I reported.
My report was about ads (often swiffy ads) which sporadically open while scrolling. This means that the scrolling actually works in my case, but as soon as I release my finger when on the ad, it will open the link sometimes.

This is quite hard to reproduce, but I stumble upon this quite regularly.
It might be related to how I move my finger, don't know for sure.

Months ago, it used to be easier to trigger this, almost 100%, by starting the scroll gesture on the ad, scroll slowly and stop, then release the finger when there is no movement anymore.
This should not open the ad, but did regularly in the past. In current releases, this does not work anymore reliably, so something seems to have improved, but not fixed.
I think this started when swiffy ads were introduced. It must have to do something how ads capture the mouse, because it does not seems to happen on regular links.

Comment 18 by, Jan 15 2016

knapp.robin: My example is based on an ad that I have tested that does this. It is a nexus 5X as reported in #10.  Here is the ad URL:
Notice the *ontouchend* handler on the body element.

We dispatch touchend only when finger is released. So while you are touching the screen the page will scroll as expected.  In the example, the Ad is (ab)using the touchend to do what should usually be done on 'click' event i.e., opening a page. So the logic in the ad, matched the behaviour you are describing as far as I can tell. I am not sure how widespread this particular usage pattern is in Ads and if it is limited to few certain bad ad or a class of ads (swiffy?).

Fast-click libraries do use a pattern where they dispatch click on touchend to avoid Mobile Safari 300ms delay. However they detect movement and avoid dispatching click if touch point has moved which prevents such bad behaviour.

Comment 19 by, Jan 15 2016

The difference is, that in my case the page scrolls correctly.
But it might indeed be related to the fast click scripts that try to optimize clicks and sporadically trigger a click like your example does.

If this is the case it might be hard to "fix" this in the browser, that's not a bug

Comment 20 by, Jan 15 2016

So, let's try something else...
After submitting the last post I just remembered that I was seeing links opening on while scrolling (this happened to me a couple of days ago).

For example, open this link:

There is are grey boxes with links to an image (on top, a street sign) and a link to a video ("VIDEO") embedded.
I rarely can reproduce the behaviour on these links, but it is really hard to trigger it. It might just be a too short scroll gesture which causes it, but it happens occasionally while browsing through these articles.

Also, near the bottom of this page, there is another grey box labelled "VIDEOEMPFEHLUNGEN" with links to other videos.
There is a quite good chance to trigger that behavior when touching the video links in the box with the scroll gesture, especially while the page is still loading (at least it seems).

Are you able to reproduce this?

Comment 21 by, Jan 20 2016

Labels: -Pri-2 Pri-1
This should be higher than Pri-2.

#20: I can repro with the VIDEO image on that link. My guess is that's just some JS intentionally triggering the link on touchend --  there's 10Ks of lines of code there.

I've also reprod this on my Nexus 6 and on desktop using emulation with other DoubleClick ads. They weren't Nexus ads.

Comment 22 by, Jan 22 2016

Labels: -Pri-1 Pri-2
I check the report on #20 as well.

The site is using FastClick library and a fairly old version of it. It has the
touch handlers to touchstart, touchcancel, touchend, on both those types of
links you mentioned above.

FastClick tries to detect click on touchend. The library is using a touch
boundary value of 10px which means that if your scroll gesture is smaller that
10px it will consider that as a click. So your guess that it only happens on
short scroll gesture is accurate. I can reproduce this on both VIDEO and links
in VIDEOEMPFEHLUNGEN when using a small scroll gesture (i.e, less that 10

Recent version of FastClick (since Nov 2013 thanks to jakearchibald@[2]) 
correctly detects mobile optimized pages in Chrome that does not need 
fast click. But alas, the site you link is using a version that is fairly old which
does not have this check. The site owner should try to update their fast click

Chrome devtools has a feature where it shows the event handler for
any elements [3]. I find that to be very useful for these kinds of debugging.

Lowering the priority because there is no indication that this is a Chrome bug
rather misbehaving web-apps and web ads. This is definitely a P1 ads bug
which is reported and tracking internally at b/26505568. If you see other
ads doing this please report them here or in that bug.

Ojan is the best person to decide whether this kind of (ab)use of "touchend" should 
be intervened by user-agent or not.

[1]	this.onTouchEnd = function() { return FastClick.prototype.onTouchEnd.apply(self, arguments); };

Comment 23 by, Jan 22 2016


Thanks a lot for analyzing this issue and for the explanation.
It seems like this is a combination of mis-implementations on the web sites and in the adverstising code and maybe how I personally use flick gestures to scroll which creates short touch movements.
So some people will see this behaviour, others won't.

I personally do not care much about the linked n-tv website, it was just an example which makes this behaviour easily reproducible and to find out what is going wrong.

I am willing to report ads that expose this behaviour, but I do not know how to link to an ad...


Comment 24 by, Jan 22 2016

Thanks #22, sorry about that. The referenced b/26505568 is more limited in scope than this bug, so I've commented there to determine the best track for dealing with issues other than the specific one(s) mentioned in that bug.

Comment 25 by, Jan 23 2016

Status: Assigned
IMO, we absolutely should do something about this on the web platform side. I'm not sure what is practical yet though. My best idea at the moment is to only allow cross-origin frames to cause navigations during a click event. That's pretty aggressive though, so will need to solicit more people's feedback, including other browser vendors.

Comment 26 by, Jan 23 2016

If anyone has thoughts on this or interest in working on it, please do get in touch with me.

Comment 27 by, Jan 23 2016

By "navigations," I meant navigations and/or opening of popups.

Comment 28 by, Jan 23 2016

This does seem to fall into intervention-land. How's this: For iframes (any iframes), if we find that we have both touchEnd and click on the stack, we can drop dispatching the click event handlers?

Comment 29 by, Jan 23 2016

Do you mean drop dispatching the touchend? That seems hard to reason about. I import one library and listens to touchend, then I import another one that listens to click and the first one stops working.

Comment 30 by, Jan 23 2016

Before we jump to an intervention, what about a new iframe option the host document can set to disable touch (and maybe also wheel) events in the frame?  This would be helpful for scroll performance too.  Would the ad networks be willing to set this on their iframes?  Not sending touch events at all is probably the safest possible thing we could do - as far as the frame is concerned a tap will just look exactly like a mouse click.

In terms of the above proposed interventions: note that in general it's common to have touch handlers just for presense detection.  It's very hard to make any assumption about behavior based on the presense of a listener (and also pretty evil - developers don't expect adding a no-op listener to have side effects).  Also we probably can't just disable navigation on touchend because many sites / libraries use fastclick libraries that consume the touchend - so navigation would be completely broken.

The right long-term solution (now that Safari 9.1 finally has decent fastclick behavior) is to push developers away from fastclick libraries to relying just on "click".  Once Safari 9.1 (iOS 9.3) ships I'll work with DevRel to do some evangelism here.

If with all that, we still have a big problem, then maybe we can explore some intervention ideas.  Eg. maybe disabling navigation from within a listener that's handling an touchend event during a scroll (i.e. one with cancelable=false).  I'd worry that affected developer would just "fix" the bugs they find by adding a setTimeout or something though.

Comment 31 by, Jan 25 2016

Or a slightly different direction: who knows the details of popup blocking?  Does popup blocking take input (eg. UserGestureIndicator) into account?  Should the rules possibly be tweaks such that scrolling doesn't count as a user gesture, at least for the purposes of

Exactly how to tweak those rules might be tricky (presumably a swipe consumed by the app would still need to count as a user gesture).  But if we've got existing pop-up blocking heuristics here, tweaking them may be a very viable short-term option.

Comment 32 by, Jan 25 2016

This seems very similar to the problems the "allow-popups" and "allow-top-navigation" iframe sandbox options are designed to solve, right?  Perhaps just a new variant of these options?  That's probably even possible to polyfill through communication between JS in the frame and parent document.

Comment 33 by, Jan 28 2016

Blockedon: chromium:582140
Filed  issue 582140  to explore modifying pop-up blocking behavior.

Comment 34 by, Mar 16 2016

Issue 576714 has been merged into this issue.

Comment 35 by, May 14 2016

Blockedon: 611981 611982
The main change for this ( issue  582140 ) has landed for M52.

After more discussion we've decided there's some more we want to do / changes we think we should make:!topic/input-dev/kVjCq9PtGgI.

 Issue 611981  tracks attempting to update the intervention to handle the buggy site cases, and  issue 611982  tracks coping with the larger issue of potentially malicious frames.

Comment 36 by, May 14 2016

Labels: -OS-Android OS-All

Comment 37 by, Jun 20 2016

Labels: Hotlist-Interventions

Comment 38 by, Jun 30 2016

Mergedinto: 582140
Status: Duplicate (was: Assigned)
No point in tracking this separately - really  issue 582140  fully addresses the problem raised here.

Sign in to add a comment