Closed Bug 705246 Opened 9 years ago Closed 7 years ago

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


(Firefox for Android :: General, defect)

Not set



Firefox 27
Tracking Status
firefox27 --- verified
relnote-firefox --- 27+
fennec 27+ ---


(Reporter: cwiiis, Assigned: wesj)



(Keywords: uiwanted, Whiteboard: ui-hackathon)


(1 file, 1 obsolete file)

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.
Keywords: uiwanted
Priority: -- → P4
Assignee: nobody →
Talked with blassey and dougt need a UX decision to the behavior. Should we overscoll or should we highlight.
Assignee: → madhava
Priority: P4 → P3
Duplicate of this bug: 710417
Duplicate of this bug: 711741
tracking-fennec: --- → 11+
It would be good to be consistent with whatever the other apps on a users phone are doing. (Implying reading the system wide pref.)
Duplicate of this bug: 715246
Duplicate of this bug: 752398
tracking-fennec: 11+ → 16+
Ian, make a call
Assignee: madhava → 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 for more details.
Closed: 8 years ago
Resolution: --- → WONTFIX
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.
Duplicate of this bug: 841545
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.
Resolution: WONTFIX → ---
Blocks: 848327
No longer blocks: 848327
Duplicate of this bug: 859330
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."
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().
Whiteboard: ui-hackathon
Having a quick look just to see how complex this actually is.
Assignee: 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)
Assignee: → nobody
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?
tracking-fennec: 16+ → ?
Priority: P3 → --
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
Assignee: nobody → wjohnston
Just want to reiterate an earlier comment, let's drop the overscroll but *no highlight* for now.
tracking-fennec: ? → 27+
Attached patch Patch (obsolete) — Splinter Review
Just to be clear, you DON'T want the highlight? That's a pretty trivial patch, so here it is. Build at:
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...
Attached patch PatchSplinter Review
This fixes the dynamic toolbar.
Attachment #804062 - Attachment is obsolete: true
Attachment #806656 - Flags: review?(bugmail.mozilla)
(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:

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]

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

LGTM if this works as expected.
Attachment #806656 - Flags: review?(bugmail.mozilla) → review+
Closed: 8 years ago7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 27
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
You need to log in before you can comment on or make changes to this bug.