705246 - Browser should show highlight instead of over-scrolling when panning beyond page boundaries

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Chris Lord [:cwiiis]]

Currently, if you try to scroll beyond the boundaries of a page, we over-scroll and snap back, similar to behaviour on iOS. This goes against Android behaviour, which is to show a radial gradient (or linear, in gingerbread) overlayed on the side you're pushing against, whose opacity is related to how 'hard' you're pushing against that edge.

I think we should behave like other Android applications in this situation - it would also, possibly, simplify the pan/zoom code somewhat.

Comment 1

[Patrick Walton (:pcwalton)]

Samsung phones actually overscroll like iOS, so this should be device-dependent. (I'd personally like a pref to force the overscroll behavior, since I like it, but we should probably default to what the device does.)

Comment 2

[[:fabrice] Fabrice Desré]

This depends on the rom you're using. On CM 7 you can just choose the behavior you like, and this would be nice to honor this choice in firefox.

Also, even when overscrolling, doing it for the left and right sides doesn't make sense I think. This is especially irritating now that pages are scaled to the screen width and that you actually don't need to pan in this direction.

Comment 3

[Kevin Brosnan [Ex-Mozilla]]

Talked with blassey and dougt need a UX decision to the behavior. Should we overscoll or should we highlight.

Comment 6

[Jonathan Watt [:jwatt]]

It would be good to be consistent with whatever the other apps on a users phone are doing. (Implying reading the system wide pref.)

Comment 9

[Brad Lassey [:blassey] (use needinfo?)]

Ian, make a call

Comment 10

[Ian Barlow (:ibarlow)]

Keep the elastic overscrolling please. 

We (UX) are exploring ways of usins the overscroll as a means to get back to about:home, where you pull down to reveal it. See https://bugzilla.mozilla.org/show_bug.cgi?id=759011#c8 for more details.

Comment 11

[José Jeria]

Would it not be possible to let the platform handle the overscroll instead of having the current simulated solution?

Comment 12

[Lucas Rocha (:lucasr)]

I really think we should reconsider this decision. Using overscroll on web content to trigger a feature in the browser UI seems a bit problematic. And it seems the direction we're taking in bug 759011 doesn't involve overscrolling at all.

I'd prefer us to be consistent with the system behaviour.

Comment 13

[Ian Barlow (:ibarlow)]

Lucas -- can you spin up a test build with system overscroll behaviour enabled? I understand your concern, but I'd like to try the system alternative before deciding whether or not to go back on our previous decision.

Comment 14

[Kartikaya Gupta (email:[e-mail])]

Just to note: doing this is non trivial at the moment, and BenWa is planning to take a crack at it in the not-too-distant future. Specifically he said he would look at using the android.widget.Scroller and android.widget.OverScroller classes to control the overscroll animation so that it could be turned on and off easily. I don't know if there's a bug filed for that though.

Comment 16

[xiaqqaix]

IIRC since ICS glow effect for overscrolling has been predominate in Android UI.

The tab screen also uses glow instead of elastics; adopting the same visual effect on pages improves UI consistence.

Perhaps consider reopen this. :)

Comment 17

[Chris Lord [:cwiiis]]

As we've been discussing this recently, I will reopen this. The inconsistency between about:home and content is a very good point.

Comment 19

[Aaron Train [:aaronmt]]

Some points from bug 859330:

"... this feature is problematic on some websites like Twitter which assigns swipe down gesture to update the timeline. We can't pull it down as our wishes, and we have to move our finger for longer distance. (The autohide toolbar is also problematic, but I don't mention it here because it is off-topic.)

In addition, this effect is incompatible with some javascript APIs of the viewport or touch event. For example, event.screenX and screenY must return the absolute coordinates of the touch event from the top left of the device screen, but the screenXY returns the coordinates from the top left of the content area while the bounce animation. Consequently, we can't determine the absolute coordinates of a user's finger within the device screen, which makes developers inconvenient."

Comment 21

[Chris Lord [:cwiiis]]

I think this might be simpler than we expect - We may just be able to use the native Android for drawing highlights and paste a widget over the LayerView. This may have performance implications perhaps, but it's worth looking at.

There's a function on ImmutableViewportMetrics called getOverscroll() that gives you a RectF of the overscroll, in pixels (then you can get the viewport size from the metrics with getWidth and getHeight) - the metrics can be gotten from the LayerView with getViewportMetrics().

Comment 22

[Lucas Rocha (:lucasr)]

Having a quick look just to see how complex this actually is.

Comment 23

[Ian Barlow (:ibarlow)]

I think if we were to move forward with this approach, I would suggest not even showing the highlight colour. It might look a little funky, and it looks like most other browsers hide it as well. 

I would like to keep the subtle bounce you encounter when you hit the end of a page or a list on Android (see the Android Settings list, for example)

Comment 24

[Loic Nageleisen]

Could it be possible to have an about:config option for now to simply disable overscrolling? Having consistent feedback with stock Android (Nexus 4 here) would be nice, actually having consistent behavior is more critical.

Comment 25

[Aaron Train [:aaronmt]]

There is nobody working on this right now.

Comment 26

[Matt Basta [:basta]]

Can we provide a prefixed CSS property to control this?

-moz-overscroll: auto; /* default */
-moz-overscroll: elastic;
-moz-overscroll: highlight;
-moz-overscroll: none;

Let the developer choose which to use, default to whatever the device uses.

Comment 27

[Aaron Train [:aaronmt]]

16 shipped. What's the plan now friends?

Comment 28

[Mark Finkle (:mfinkle) (use needinfo?)]

Throwing at Wes to play with in his free time. I would look at separate patches that:
1. Drop the overscroll
2. Add the highlight

Comment 29

[Ian Barlow (:ibarlow)]

Just want to reiterate an earlier comment, let's drop the overscroll but *no highlight* for now.

Comment 30

[Wesley Johnston (:wesj)]

Attachment: Patch

Just to be clear, you DON'T want the highlight? That's a pretty trivial patch, so here it is. Build at:

http://people.mozilla.org/~wjohnston/overscroll.apk

Comment 31

[Paul [pwd]]

No highlight and no over scroll

Comment 32

[Chris Lord [:cwiiis]]

it's worth noting that the latest version of Chrome added the over-scroll highlight. I really think platform consistency trumps visual design here...

Comment 33

[Wesley Johnston (:wesj)]

Attachment: Patch

This fixes the dynamic toolbar.

Comment 34

[Ian Barlow (:ibarlow)]

(In reply to Wesley Johnston (:wesj) from comment #30)
> Created attachment 804062 [details] [diff] [review]
> Patch
> 
> Just to be clear, you DON'T want the highlight? That's a pretty trivial
> patch, so here it is. Build at:
> 
> http://people.mozilla.org/~wjohnston/overscroll.apk

Looks great. Ship er

One thing we'll want to fix in a follow up is disabling being about to zoom out beyond the boundaries of a page

Comment 35

[Kartikaya Gupta (email:[e-mail])]

Comment on attachment 806656 [details] [diff] [review]
Patch

Review of attachment 806656 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM if this works as expected.

Comment 36

[Wesley Johnston (:wesj)]

https://hg.mozilla.org/integration/fx-team/rev/47424114abeb

Comment 37

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/47424114abeb

Comment 38

[Paul [pwd]]

I think this may have been marked fixed a little prematurely. While the overscroll has indeed been eliminated, so have the highlight.

Also about:firefox appears to be around 5px too wide.

Comment 39

[Aaron Train [:aaronmt]]

(In reply to Paul [sabret00the] from comment #38)
> I think this may have been marked fixed a little prematurely. 

That's why it's on Nightly (see bug 918079).

> Also about:firefox appears to be around 5px too wide.

File a new bug.

Comment 40

[Paul [pwd]]

(In reply to Aaron Train [:aaronmt] from comment #39)
> (In reply to Paul [sabret00the] from comment #38)
> > I think this may have been marked fixed a little prematurely. 
> 
> That's why it's on Nightly (see bug 918079).
Perhaps the title of this bug should be fixed to match the patch?

> > Also about:firefox appears to be around 5px too wide.
> 
> File a new bug.
Done, see bug 920279