New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
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

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

Reported by, Aug 19 2016 Project Member

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


Comment 2 by, Aug 22 2016

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

Comment 3 by, Aug 22 2016

Blockedon: 639227

Comment 4 by, Aug 23 2016

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.

Comment 5 by, Sep 27 2016

Labels: Hotlist-Input-Dev

Comment 6 by, Sep 28 2016

[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.


Comment 7 by, Sep 28 2016

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

Comment 10 by, Nov 1 2016

Labels: -M-55 M-56

Comment 11 by, Nov 18 2016

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.

Comment 12 by, Nov 21 2016

> 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.

Comment 13 by, Nov 21 2016

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.

Comment 14 by, Nov 21 2016

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.

Comment 15 by, Nov 21 2016

 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.

Comment 16 by, Jan 16 2017

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