Sublayer elastic band effect on Mac

[Timothy Dresser]

I'm working on aligning our touchpad scrolling behavior with Safari's by getting rid of scroll chaining (bug here).

Instead of chaining, Safari has an elastic band effect on all scrollers, not just the root scroller. Chris, do you have any idea how difficult that would be to implement in Chrome?

Tim

[Christopher Cameron]

On Tue, Oct 20, 2015 at 10:20 AM, Timothy Dresser <tdre...@chromium.org> wrote:

I'm working on aligning our touchpad scrolling behavior with Safari's by getting rid of scroll chaining (bug here).

(bug link doesn't work).

 

Instead of chaining, Safari has an elastic band effect on all scrollers, not just the root scroller.

This is true, but it is disabled on every scroller except the root scroller. The last remnant of this was deleted in https://codereview.chromium.org/977663002, but if you look at the diffs, you can trace through this as follows:

• Rubber banding is done in ScrollAnimatorMac::handleWheelEvent
  
• This calls allowsHorizontalStretching / allowsVerticalStretching to determine if it will do any rubber-banding
• This hits ScrollAnimatorMac::allowsVerticalStretching
  
• This hits ScrollableArea::verticalScrollElasticity
• This defaults to ScrollElasticityNone
• And is only overridden for the FrameView, in its ctor FrameView::FrameView 

Chris, do you have any idea how difficult that would be to implement in Chrome?

So, we don't want to do this -- the complicated WebKit implementation makes very unclear, but, rubber banding is only implemented for the root.

Now, Safari has some thing in recent versions where (e.g, on Twitter) top-Chrome will will not move with the over-scroll. I suspect that if the bug is that we're trying to get that effect, then we should go with the following strategy.

We currently don't move the scrollbars with the overscroll (they are higher up in the layer hierarchy than the layer that does the effect). We probably just want to move the top-stuff to be in that same bucket.

Of note is that we do not properly translate input events for the scrollbars  -- it's really hard to grab a scrollbar while doing an over-scroll, so we figured that nobody would notice, and I think that's right. If we're applying this to top-stuff as well, we may want to re-think this.

[Tim Dresser]

Sorry, bug link here.

So if we do get rid of scroll chaining, how should we behave when you hit the scroll extent of a non-root scroller? Should we just not rubber band at all?

[Christopher Cameron]

On Tue, Oct 20, 2015 at 12:11 PM, Tim Dresser <tdre...@google.com> wrote:

Sorry, bug link here.

So if we do get rid of scroll chaining, how should we behave when you hit the scroll extent of a non-root scroller? Should we just not rubber band at all?

Okay, very interesting -- trying Safari today, they appear to support overscroll on non-root elements, and they appear to do latching. I wonder when they changed this.

So maybe we should rethink how overscroll works.

[Alexandre Elias]

This seems to have changed recently on iOS Safari as well.  In the past, overscroll rubberbanding on subelements happened only when "-webkit-overflow-scrolling: touch" was set on those scrollers (which is their magic property to activate "fast path" scrolling).  On the iOS9 version of iOS Safari, I see it on all scrollable elements.

[Christopher Cameron]

As to how to implement this, perhaps replicating the various overscroll parameters and controller, per-layer, is the way to go? Unfortunately I haven't kept in sync with the architectural tectonics of the input system, so my suggestions may not be on-target.

[Alexandre Elias]

Yeah, that sounds about right.

There's also a longstanding identical problem that the Android overscroll glow only works on the root layer: http://crbug.com/365804.  Fixing that could be made part of the same project, although the requirements are a bit different: Android needs to overlay a separate texture instead of translating the layer offset.  Although I expect we can find a superset of velocity information that can drive both kinds of effect.

[Rick Byers]

I guess we have the same conceptual problem on Android now that we've enabled touch scroll latching: there's no visual affordance at all for overscroll of a sub-scroller (and some scenarios that previously would have triggered the glow now do not).

I like the idea of tackling these together at some point, but as I expect it's non-trivial I'm not sure what priority to give it.  Perhaps it's worth trying to ship latching first without this and see what people think about it.  If we find other reasons why we can't do latching than this may all be less important anyway.

[Tim Dresser]

Sounds good - I'll ignore it for the moment.