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

Issue 162179 link

Starred by 24 users

Support a way to limit scroll chaining (eg. past position:fixed elements)

Project Member Reported by klo...@chromium.org, Nov 21 2012

Issue description

Application Version (from "Chrome Settings > About Chrome"): Chrome Dev 1331518
Android Build Number (from "Android Settings > About Phone/Tablet"): Phone

Steps to reproduce: 
Load gmail.com
Scroll up and down

Observed behavior: 
Header is not locked during scrolling. 

Expected behavior: 
Same behavior as Chrome m18

 
I the problem shows up because we are bubbling scroll deltas outside overflow divs unlike on M18.

I'm not sure the bubbling is the real issue here, but instead the length of the page is changing as the icon bar appears/disappears and this somehow causes us to scroll too far at the end. Also, when the icons are shown when you start scrolling, they immediately disappear and the touch event gets dropped. This may be a javascript issue.
Labels: Area-WebKit WebKit-Compositing

Comment 3 by laforge@google.com, Nov 27 2012

Labels: Project-Refresh

Comment 4 by klo...@chromium.org, Dec 18 2012

Cc: peter@chromium.org skyos...@chromium.org
Owner: joh...@chromium.org
We need to decide whether we will stop bubble for "-webkit-overflow-scrolling: touch;" or we introduce another property to stop bubble.

John/Peter, can you two work out a solution for this before the new gmail goes to public?
Cc: miguelg@chromium.org
John, any update on this? 
Labels: -Project-Refresh
Blocking: chromium:162644

Comment 8 by k...@google.com, Jan 8 2013

Labels: -ReleaseBlock-Beta ReleaseBlock-Stable
Issue 162475 has been merged into this issue.
Also see  issue 134520  which changes the propagation rules for scrolling.
Sami and I looked into this, and I think there are 2 short-term action points:

1. In m18, although slow touch scrolls bubbled up to enclosing scrollables, we didn't do that for flings, as would be confusing for a fling to scroll multiple scrollable layers. Currently m25 does it for both slow touch scrolls and flings, so we should fix that as it makes this significantly worse. I'll file a bug blocking this one.

2. There's a bug in the gmail.com CSS/JS, which makes this worse (i.e. when you scroll past the bottom of your emails, a white bar scrolls in at the bottom of the screen, and the top toolbar scrolls offscreen). I'll file that with the superpudu team.

Once those two are fixed, the only remaining issue is that when you scroll past the top of your emails, the top toolbar scrolls down and reveals the Google+, Gmail, Calendar and Web icons. This isn't particularly shocking, in fact the app seems to intend for these to be revealed if you drag the blue toolbar down, but the Superpudu folks apparently don't want these to be revealed when you scroll past the top of your emails. 4 possible ways of fixing that:

a) Add some kind of CSS property for controlling whether scrolling bubbles up. It shouldn't be limited to touch, as similar things happen for mousewheel and keyboard scrolling. It would need proper discussion with standards folks, and I don't think it's likely we can get such a property in for the M25 time frame.

b) Superpudu switches to some other approach for the onebar, which doesn't rely on the main page being scrollable.

c) Superpudu decide it's not so bad now 1 and 2 are fixed (and possibly tweak the behavior to avoid snapping the position of the onebar).

d) We give up on having slow touch scrolls bubble up except when at the start of the touch the inner scrollable is already fully scrolled. Though this would be shame, as that seems to work well in general.
Cc: jmckinley@google.com johnbarr@google.com mizatt@google.com
Looping in SP folks - given we are discussing options that may involve changes in SP.
Cc: balogan@google.com
Grace does this bug need to be restrict-view-google or can we open it up for easier editing by the superpudu team?

Comment 15 by balogan@google.com, Jan 10 2013

@johnme: could elaborate the on the bug in Superpudu with the white box, or link to the appropriate bug? I've never seen this before.
Labels: -Restrict-View-Google
Remove Restrict-View-Google
For a-d ways mentioned in #11, I think we should start with (a) now. It will take some time, so we will miss m25. But it is a good long term solution.
Cc: aelias@chromium.org
Blockedon: chromium:169548
I've been looking into this some more, and one thing I find odd is that Mobile Safari always bubbles up scrolls if when you start scrolling the inner scrollable has fully scrolled (i.e. you can't scroll both in a single continuous gesture, as you can in Clank). It does this even if you specify -webkit-overflow-scrolling:touch. So the m18 behavior of  -webkit-overflow-scrolling:touch really doesn't seem like a good idea, as it's not even compatible with iOS.

The strange thing is that when you use gmail.com on iOS the touches never bubble up. So gmail must be doing something clever to prevent this. I suspect it's somehow related to the "Pull down to refresh" feature. Gmail folks: could you use the same technique on Android as you use on iOS to prevent touches from bubbling?

Re 1., I've filed  issue 169548  to track implementing that.

Re 2., I've filed http://b/7991266 which explains the strange white bar on gmail.com that allows the top toolbar to scroll offscreen.

Gmail folks: does b/7991266 make sense? Do you agree that us fixing  issue 169548  and you fixing b/7991266 would get acceptable UX for now, and we'll start working to add finer-grained control, to land in some future revision of Chrome?

Clank folks: Feel free to have a go at  issue 169548  if you have spare cycles. If not I know the theory but have never seen the code, so I'll try to get Sami to explain what needs doing on Monday (while distracting him at little as possible from the code yellow)...
I suspect the pull-to-refresh "technique" involves a big touch handler that intercepts every touch, and I strongly want to discourage that.  We need to provide declarative alternatives to this kind of thing or we'll never be able to have consistent performance.
Alex, gmail always has the touch handler. In touch start, if the touch is in the scrollable area and the current top is not just hiding the top toolbar, it will consume the touch and scroll the page to that point.

The following site describes a way to do pull-to-refresh. Haven't checked whether gmail uses the similar way.
http://damien.antipa.at/2012/10/16/ios-pull-to-refresh-in-mobile-safari-with-native-scrolling/

In this approach, it expects the "-webkit-overflow-scrolling" div can scroll to the negative scrollTop, not bubbling up. We didn't implement it this way. If we want to match iOS, we may need to consider it.

Cc: yus...@chromium.org
Labels: -Mstone-25 -ReleaseBlock-Stable Mstone-26
Since  issue 169548  tracks part 1 and is itself ReleaseBlock-Stable (thanks yusufo), it seems this bug (which is now focused on the final step of how to expose greater control over bubbling) no longer needs ReleaseBlock-Stable, since as per comment #17 we expect that part to miss m25.
Blocking: -chromium:162644
Blocking: chromium:162475
Cc: rbyers@chromium.org tabatkins@chromium.org
+tabatkins, rbyers

I talked to Tab about this, and he had some thoughts/suggestions:

1. If we implemented touch-action:none from the Pointer Events spec[1], then you could do the following to prevent touch scrolls from bubbling:

    <div id="header">...</div>
    <div id="wrapper" style="touch-action: none;">
        <div id="scrollable" style="overflow-y: auto;">
            ...
        </div>
    </div>

Touch scrolling elements within #scrollable would scroll as usual, and if #scrollable was already scrolled as far as possible then the touch event would bubble up but it would reach the touch-action:none div, which would eat the event and prevent us from performing any default actions like scrolling the page.

Rick: are we interpreting touch-action:none correctly, and if so does implementing touch-action:none ahead of the rest of Pointer Events sound reasonable, and something that we could do in the reasonably short term?

2. That would only cover touch scrolling though, not mousewheel or keyboard scrolling. That's fine for mobile gmail, but it would be nice to have a general solution for controlling scroll bubbling as I initially suggested. Tab is has added this to his list of things to consider when he next looks at scrolling.

3. The long term plan to enable websites to implement things like pull-to-refresh with glorious compositor-acceleration and simple markup is:
https://docs.google.com/document/d/1vRUo_g1il-evZs975eNzGPOuJS7H5UBxs-iZmXHux48/edit
(see the <<Twitter's "Pull to Refresh">> example).
Blocking: chromium:173260
Cc: fredjk@google.com
Summary: Support a way to control bubble across scrollable divs / alternative to webkit-overflow-scrolling:touch (was: Mobile gmail.com scrolling is incorrect)
Labels: Feature-Touch OS-Chrome OS-Windows
John and I talked in person about this but I realized I didn't update the bug.
No, touch-action isn't really intended to be used that way - it only applies at the start of a touch and according to the (now clarified) algorithm in the spec (https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#the-touch-action-css-property) in the scenario you describe we'd only look up to scrollable, any touch-action on wrapper is irrelevant.

However, IE10 includes a simple CSS property explicitly for this scenario: -ms-scroll-chaining (http://msdn.microsoft.com/en-us/library/windows/apps/hh466007.aspx).  It takes two values, 'chained' (the default) and 'none'.  I've talked with Jacob Rossi (IE team, pointer events editor) and it sounds like they would support standardization of this property.  I suggest we approach the CSS WG to define 'scroll-chaining' (or scroll-bubbling if you prefer) in this simple way.

Tab, what do you think?
By the way, if anyone wants to play with this in IE10, here's a simple fiddle that demonstrates it (and can demonstrate that using touch-action doesn't work): http://jsfiddle.net/tg6yv/4/
Labels: -Mstone-26 Mstone-27
Ah, interesting.

Seems very unlikely we'll get this standardized and implemented by m26, given we're already past the branch point. But it would be nice to get this on the standards track in time for us to try and get it into m27, if Tab thinks this is sensible.
Is M27 realistic given that we need to standardize the element? Not sure how long this would typically take.
In order to maximize our chances for M27 is it realistic to start working on the implementation at the same time?
Labels: -Pri-1 Pri-2
Two updates:


1. Immediate cross-browser solution.

I had a play around, and it seems that the exact effect desired in gmail is already possible in a cross-browser fashion (rather than relying on legacy Android-specific quirks).

Please take a look at http://jsbin.com/gmail-scroll/10/edit (and load http://jsbin.com/gmail-scroll/10 on a phone to view it).

It uses a touch event listener on the top toolbar, allowing you to drag it up and down, and the emails themselves are scrolled using a standard overflow-y:auto (so hardware accelerated on the compositor thread as usual).

I can confirm that this works in both Chrome for Android m25 and on iOS 6 Mobile Safari. And with the appropriate -moz-, -ms- and -o- vendor prefixes it should work in other browsers too.

It also performs very well, since scrolling through emails is fully accelerated, and dragging the toolbar up/down only requires a single layout at the start and/or end of the touch, then during the drag just efficiently manipulates -webkit-transform (as long as the main thread isn't excessively clogged up by unrelated JavaScript anyway).

Hence I would recommend using this approach as a cross-browser solution to implementing the toolbar, rather than waiting for any new CSS properties.


2. Possible future solution.

I spoke to Tab, who's planning to write up a scrolling spec together with Jacob Rossi, aiming for before the end of the month, likely including scroll-chaining (or some synonym thereof).

Given that, it's feasible that we could try to implement such a -webkit-scroll-chaining property right now, and *might* be able to land it before the m27 branch point.

But it doesn't seem clear any more how high priority such a feature addition is, given that there's already a working cross-browser way of doing this. Tentatively lowering this issue to Pri-2 while I wait to hear back.
Cc: danbrotherston@google.com
Really like #35.1. Thanks John !! That seems to be very viable option to pursue given it seems broadly relevant. 

John, mind opening a bug about the weird scroll behavior you saw with your prototype? I know you managed to work around it but let's still try to fix the problem :)
Project Member

Comment 38 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Mstone-27 -Area-WebKit -WebKit-Compositing -Feature-Touch Cr-Content Cr-UI-Input-Touch Cr-Content-Compositing M-27

Comment 39 by laforge@google.com, Mar 15 2013

Labels: -Cr-UI-Input-Touch Cr-UI-Touch

Comment 40 by laforge@google.com, Mar 15 2013

Labels: -Cr-UI-Touch Cr-UI-Input-Touch
Labels: -Cr-UI-Input-Touch Cr-UI-Input-Touch-Screen
Labels: -M-27 M-28
[Triage] M27 has passed. Moving P2s to M28 after reviewing them.
Project Member

Comment 43 by bugdroid1@chromium.org, Apr 5 2013

Labels: -Cr-Content Cr-Blink
Project Member

Comment 44 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content-Compositing Cr-Blink-Compositing
Labels: -M-28 M-X
Owner: bokan@chromium.org
Summary: Support a way to control bubble across scrollable divs (was: Support a way to control bubble across scrollable divs / alternative to webkit-overflow-scrolling:touch)
bokan@ is going to experiment with implementing scroll-chaining as an experimental feature - it should be easy to do (but still need to get it standardized).
Labels: -M-X M-31 Iteration-87
See also related  issue 173403 
Labels: Iteration-88
Labels: iteration-89
Labels: Iteration-90
Labels: -M-31 M-32

Comment 52 by bokan@chromium.org, Sep 30 2013

Status: Started
Labels: Iteration-91
Labels: Iteration-92
Cc: rjkroege@chromium.org jdduke@chromium.org astrange@chromium.org jam...@chromium.org tdander...@chromium.org bokan@chromium.org conradlo@chromium.org
 Issue 173403  has been merged into this issue.
 Issue 173403  has been merged into this issue.
Labels: -Cr-UI-Input-Touch-Screen Cr-Internals-Input-Touch-Screen
Labels: Cr-Blink-Input
Labels: iteration-94
Labels: -M-32 M-X
Issue 135932 has been merged into this issue.
Blockedon: chromium:410974
Scroll customization work (ie. beforescroll - issue 410974) will address this scenario.

Status: Assigned
In particular, in the beforescroll proposal, you should be able to implement -ms-scroll-chaining: none on an element elem with:
  elem.addEventListener('beforescroll', function(e) {
    e.stopPropagation();
  }

We may also want to support a convenience scroll-chaining CSS property.  See this www-style thread for discussion of inclusion of "scroll-chaining" in a future CSS spec: http://lists.w3.org/Archives/Public/www-style/2014Sep/0355.html
Cc: -danbrotherston@google.com
Labels: Hotlist-Input-Dev

Comment 66 by bokan@chromium.org, Mar 31 2015

Owner: ----
Status: Available
Cc: tdres...@chromium.org
Labels: -OS-Android -OS-Chrome -OS-Windows -M-X -Cr-Blink -Iteration-87 -Iteration-88 -iteration-89 -Iteration-90 -Iteration-91 -Iteration-92 -iteration-94 Type-Feature OS-All
Labels: -Cr-Blink-Compositing

Comment 69 by bmau...@fb.com, Jan 12 2016

Labels: DevRel-Facebook
This issues is actually not about "scroll chaining".  With -ms-scroll-chain:none, the ancestor can still be scrolled when the descendant is at its extent.  We're just planning on removing scroll chaining from Chrome entirely (touchscreen done, touchpad is WIP  issue 526423 ).

This is about completely blocking scrolls on one node from reaching the viewport.  Scroll customization will permit this.  The other option is to restructure your DOM so the document is never scrollable (but has a full size overflow scroll div).  On mobile you really need non-document root scrollers to do that well ( issue 505516 ).  But what about desktop?
Rick, is this about overlays like navigation drawer? For example, I see Google+ doing weird trick to make it work -- overlay, overflow body and change size, shift content with transform. But general solution here is to just prevent scrolling when overlay reached its end and user tries to scroll in that direction.
Owner: tdres...@chromium.org
Assigning to tdresser@ as it is dependent on scroll customization. 
Status: Assigned (was: Available)
Owner: majidvp@chromium.org
Reassigning scroll customization work to Majid.
Cc: n...@facebook.com
Summary: Support a way to limit scroll propagation (eg. past position:fixed elements) (was: Support a way to control bubble across scrollable divs)
Talking more with n8s@ from Facebook it seems this may be the only reason that Facebook needs non-passive wheel listeners (and so isn't getting threaded scrolling).

Perhaps we should prioritize a solution that doesn't depend on full scroll customization (which is still going to take awhile)?  From  issue 173403  it sounds like changing the default propagation behavior for position:fixed probably isn't a good idea.  But perhaps we could define a simple API for this?  Eg:

scroll-propagation: blocked | allowed

As a next step I suggest we try hacking up such a simple API behind a flag.  n8s@ said he'd be happy to experiment with that to see if they could replace all their non-passive usage of wheel listeners.  If they could, then that would probably be enough reason to start up a WICG proposal for such a simple API.

Note that this is really no more powerful than 'touch-action' (which can also disable scrolling that occurs over a given element), it just generalizes an aspect of it to multiple pointing devices.  Another option would be to define an exact analog of touch-action for this, 'wheel-action'.  That could be extended for cases like 'pan-y' as well.  But that would have the downside of not applying to keyboard.  In cases like Facebook's, I think you really want a generic "terminate scroll propagation here" that applies to all input devices.

Since this could be a little tricky to implement (eg. for now would probably want it to create a layer, or force main thread scrolling if the element isn't already promoted), perhaps for the Facebook experiment we should just start with a flag to block propagation past fixed position elements like bokan@'s patch here: https://codereview.chromium.org/25629006?

bokan/majidvp/tdresser thoughts?

Comment 76 by ojan@chromium.org, Sep 28 2016

Just to make sure I understand the proposal.

allowed: Our current behavior of latching any given scroll, but bubbling the scroll to the next scrolling ancestor if the current one is already scrolled all the way to the scroll extent.

blocked: Same as our current behavior, but never bubble up from the blocked scroller. Scrollers inside the blocked scroller could still bubble up to it (i.e. this property would not be inherited).

Is that right?
Yes, that is correct.  Thanks for the clarification.

Note that (consistent with the scroll customization model) this means that browser overscroll actions (pull to refresh, overscroll glow) also would not occur for any scrolls over an element marked 'scroll-propagation: blocked'.
I feel it makes sense to have scroll propagation be controlled independently for each axis. For example a component which does not overflow on horizontally should not prevent propagation on that axis if it only needs to prevent the vertical propagation. 

The proposed syntax does not allow that but something similar to 'overflow' can work e.g., scroll-propagation-{x,y} with scroll-propagation being a short-hand.



Summary: Support a way to limit scroll chaining (eg. past position:fixed elements) (was: Support a way to limit scroll propagation (eg. past position:fixed elements))
Majid pointed out that my comment in #70 is incorrect.  This is EXACTLY -ms-scroll-chaining.  That API doesn't simply opt-in to latching, but does completely control all propagation (based on http://jsbin.com/biqiko behavior on Edge mobile).  Sorry for the confusion.
Status: Started (was: Assigned)
I have started discussions [1,2] to change -ms-scroll-chaining to be able to address this use-case. 

[1] WICG: https://discourse.wicg.io/t/generic-scroll-chaining-prevention-mechanism-or-expand-standardize-ms-scroll-chaining/1811
[2] www-style: https://lists.w3.org/Archives/Public/www-style/2016Nov/0055.html
Blockedon: -410974 672921
As I understand,  issue 672921  is the currently proposed solution for this problem.
Cc: majidvp@chromium.org pnangunoori@chromium.org dtapu...@chromium.org sunyunjia@chromium.org ligim...@chromium.org
 Issue 750477  has been merged into this issue.
Labels: M-63
Status: Fixed (was: Started)
Our standardization effort mentioned in #80 have been successful and we 
have not the "overscroll-behavior" property that is going to ship in Chrome
M63 (and hopefully in other browsers soon).

Here is a blog post on this feature and usage [1], chromestatus entry [2] and 
draft specification [3].

[1] https://developers.google.com/web/updates/2017/11/overscroll-behavior
[2] https://www.chromestatus.com/features/5734614437986304
[3] https://wicg.github.io/overscroll-behavior/

Is this actually FIXED fixed? 5 year old bug? Well done everyone!
Indeed! Awesome!

Sign in to add a comment