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.
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.)
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.
Talked with blassey and dougt need a UX decision to the behavior. Should we overscoll or should we highlight.
It would be good to be consistent with whatever the other apps on a users phone are doing. (Implying reading the system wide pref.)
Ian, make a call
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.
Would it not be possible to let the platform handle the overscroll instead of having the current simulated solution?
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.
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.
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.
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. :)
As we've been discussing this recently, I will reopen this. The inconsistency between about:home and content is a very good point.
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().
Having a quick look just to see how complex this actually is.
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)
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.
There is nobody working on this right now.
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.
16 shipped. What's the plan now friends?
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
Just want to reiterate an earlier comment, let's drop the overscroll but *no highlight* for now.
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
No highlight and no over scroll
it's worth noting that the latest version of Chrome added the over-scroll highlight. I really think platform consistency trumps visual design here...
Created attachment 806656 [details] [diff] [review] Patch This fixes the dynamic toolbar.
(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 on attachment 806656 [details] [diff] [review] Patch Review of attachment 806656 [details] [diff] [review]: ----------------------------------------------------------------- LGTM if this works as expected.
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.
(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.
(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