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

Issue 639433 link

Starred by 3 users

Issue metadata

Status: WontFix
Closed: Jan 2017
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug-Regression

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Touch events always cause scrolling even on content where they're not supposed to

Project Member Reported by, Aug 19 2016

Issue description

Version: 54.0.2830.0 (Official Build) dev (32-bit)
OS: Android 7.0

What steps will reproduce the problem?
(1) Navigate to (can be found with a search for "nytimes jupiter interactive"
(2) Click and drag to spin the globe.

What is the expected output?

Expect the page to stay fixed in place and the globe to spin.

What do you see instead?

Touch and drag events always induce scrolling.

This is a regression on Dev Channel within the past couple of weeks. I don't know how to bisect efficiently on Android (does work there? doesn't look like it).

I haven't had time to debug the content and make sure it's correctly calling Event.preventDefault(), but given that it works properly on Stable and used to work properly on Dev, I suspect it is.

I'm marking Release-Block-Stable because there's a definite possibility this will regress real content.

tabatkins@ mentioned this might be related to passive event listeners but I'm not sure about that -- it looks like they were added in Chrome 51, and this is a recent regression in Chrome 54.


Comment 1 by, Aug 20 2016

Status: Assigned (was: Untriaged)
This is due to the passive document listeners intervention ( issue 625675 ).

Comment 3 by, Aug 22 2016

Blockedon: 639227
Adding touch-action: none to the g-scroll div's style fixes the issue. I'm going to try some outreach and see if they can add this to their page.
Labels: Hotlist-Input-Dev
[Bulk edit]

This issue is listed as a release block stable for M54 Android.  We'll be cutting our stable candidate in just about two weeks, so time is running out to fix this bug - please prioritize working on it ASAP.

Are you sure this issue shouldn't block the release?  Remove the ReleaseBlock-Stable label.
Unsure if this issue should block the release, or know the issue should block the release but we won't be able to fix it in time?  CC me so that we can discuss.

Labels: -M-54 M-55

Comment 8 by, Oct 20 2016

Was there any response from the New York Times? This stopped happening in my instance of Chrome Dev, but I think that's because the experiments were reset.

Setting "Passive Event Listener Override" to "True (when unspecified)" causes the broken behavior again.

Comment 9 by, Oct 20 2016

Blockedon: -639227
Blocking: 639227
Labels: -M-55 M-56
Blocking: -639227
Labels: -Pri-1 -Needs-Bisect -ReleaseBlock-Stable Pri-3
Status: ExternalDependency (was: Assigned)
Marking as external dependency; decreasing priority and removing blocking label. We've nytimes reached out to them a few times but no response. This is easily fixable with touch-action.
> This is easily fixable with touch-action.

Yes, that might be true (or might not: See  issue #662047 ).
However that's not how the web should work. If the UA introduces a regression for which there is a workaround, the regression should still be fixed instead of the whole web should adjust to some UAs mis-interpretation of a specification. 
Yes but this is a expected side-effect of the change we introduced to force event listeners as passive on root document elements. We discussed this openly on the blink-dev and intervention-dev mailing lists. It is a calculated judgement that we have made and from our data gathering doesn't cause many regressions such as this but benefits the user greatly.
OK - understood, the web will need to change when Chrome makes a breaking change. So far, so "good".
But how should the web change? You say "this is easily fixable with touch-action". Is this still true for the upcoming versions when the new pointer events API will become available? Please cross-check your statement with regards to  issue #662047 .

On a side note: I still don't see why the UA cannot just realize that the code *explicitly* calls preventDefault(). The UA could just probe the listener for the first invocation and if the listener does not prevent the default make the listener automatically a passive listener unless the listener is explicitly defined as active, of course. Why do we explicitly need to call preventDefault *and* mark the event as passive (which is the default)? In probably more than 99% of the cases it would just take a single event invocation to find that the listener prevents the default and that this change now breaks the developer's intended behavior. 

 Issue 662047  sounds like it is a windows specific bug how touch is being handled. I don't believe it has anything to do with this bug.

Yes that is one approach to let the UA fire the event listener the one time but it also causes a few problems 1) it is unpredictable; being rational (ie a fixed model is easy for developers to understand). 2) It doesn't give the first interaction as being fast. Yes you'll have to wait for that first response to come back but oh there is the touch ack timeout that fires (which we want to get rid of as well). 

Our ultimate goal is to treat all touch events as passive (unless explicitly declared) so they act very similar to pointer events; it isn't clear we can do that just yet so we are only doing it for root level document listeners which are generally used on analytics to track site engagement.

Status: WontFix (was: ExternalDependency)
Outreach / documentation for this is live here:

I think we've now done all we're going to do in this nytimes case (hopefully it's enough to get sites like this updated shortly after 56 hits stable).  Closing this (feel free to re-open if you disagree).

Sign in to add a comment