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

Issue 812790 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug

Blocked on:
issue 611982



Sign in to add a comment

Mobile ad prevents scrolling on page

Project Member Reported by zea@chromium.org, Feb 15 2018

Issue description

The ad appears to be getting triggered if I scroll on the page and my initial tap is on the UI surface for the ad. So, the steps would be.
1. Load a page with one of these ads, which may take up a large portion of the page
2. Finger down on the ad
3. Swipe to initiate the scroll
4. Finger up somewhere off the ad

Expected result:
page scroll

Actual result:
Ad opens in a new navigation within that tab

I've seen this behavior before, but it appears to only be triggered by certain ads that I can't reliably fetch.

I've attached a screenshot of the ad that most recently resulted in this behavior if that helps (wasn't able to get any more info at the time). 

Not sure how to best triage this. Chris, perhaps this might relate to the work your team is doing around ads? Alternatively, is it a bug in the first place that this ad can cause this behavior?
 

Comment 1 by zea@chromium.org, Feb 15 2018

Actually attaching screenshot this time
Screenshot_20180215-074810.png
578 KB View Download
Cc: rbyers@chromium.org
+rbyers for general input handling

I would assume in this case the ad should get a touchdown and either a touchup/cancel.  I guess I don't know if we do anything to prevent them from taking action on the latter case.  I would expect they'd always get "some" signal that the touch stream has ended and they could act on it (even if the final event was outside of their bounds...I guess I'd expect a cancel when leaving, but that is why I added rbyers to correct my lies).

Comment 3 by rbyers@chromium.org, Feb 16 2018

Blockedon: 611982
Cc: dtapu...@chromium.org
We're exploring interventions for this is in  issue 611982  (could just call this a dupe of that).  If this is a google ad, then it's in violation of Google policies and can be reported.

Comment 4 by cbentzel@google.com, Feb 16 2018

Is this particular case a sandboxed iframe? I would be interested in applying that policy if we think it is an ad regardless of whether sandboxing has been used.

Comment 5 by rbyers@chromium.org, Feb 16 2018

Cc: iclell...@chromium.org
I'd be OK with heuristics for policies like that as long as we have both explicit opt-in and opt-out.  I think that just requires two different features today.

Comment 6 by zea@chromium.org, Feb 16 2018

Looks like these are Google ads running in an iframe (pulled up the site on desktop in devtools mobile mode):

<iframe frameborder="0" src="http://tpc.googlesyndication.com/safeframe/1-0-15/html/container.html" id="google_ads_iframe_/4817/bbccom.live.site.mobile.news/news_uscanada_content_1" title="3rd party ad content" name="" scrolling="no" marginwidth="0" marginheight="0" width="300" height="250" data-is-safeframe="true" style="border: 0px; vertical-align: bottom;" tabindex="-1"></iframe>

Comment 7 by bauerb@chromium.org, Feb 20 2018

Labels: android-fe-triaged
Status: Available (was: Untriaged)

Sign in to add a comment