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

VERIFIED FIXED in Firefox 27

Status

()

Firefox for Android
General
VERIFIED FIXED
6 years ago
10 months ago

People

(Reporter: cwiiis, Assigned: wesj)

Tracking

({uiwanted})

unspecified
Firefox 27
ARM
Android
uiwanted
Points:
---

Firefox Tracking Flags

(firefox27 verified, relnote-firefox 27+, fennec27+)

Details

(Whiteboard: ui-hackathon)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

6 years ago
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
(Reporter)

Updated

6 years ago
Assignee: nobody → chrislord.net
Talked with blassey and dougt need a UX decision to the behavior. Should we overscoll or should we highlight.
Assignee: chrislord.net → 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 https://bugzilla.mozilla.org/show_bug.cgi?id=759011#c8 for more details.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX

Comment 11

5 years ago
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

Comment 16

4 years ago
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. :)
(Reporter)

Comment 17

4 years ago
As we've been discussing this recently, I will reopen this. The inconsistency between about:home and content is a very good point.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Blocks: 848327
(Reporter)

Updated

4 years ago
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."
Blocks: 787629
No longer blocks: 787629
Depends on: 787629
See Also: → bug 673875
(Reporter)

Comment 21

4 years ago
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 → lucasr.at.mozilla
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)

Updated

4 years ago
Assignee: lucasr.at.mozilla → nobody

Comment 24

4 years ago
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.

Comment 26

4 years ago
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
Status: REOPENED → NEW
Just want to reiterate an earlier comment, let's drop the overscroll but *no highlight* for now.
tracking-fennec: ? → 27+
(Assignee)

Comment 30

4 years ago
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

Comment 31

4 years ago
No highlight and no over scroll
(Reporter)

Comment 32

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

Comment 33

4 years ago
Created attachment 806656 [details] [diff] [review]
Patch

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:
> 
> 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.
Attachment #806656 - Flags: review?(bugmail.mozilla) → review+
(Assignee)

Comment 36

4 years ago
https://hg.mozilla.org/integration/fx-team/rev/47424114abeb
https://hg.mozilla.org/mozilla-central/rev/47424114abeb
Status: NEW → RESOLVED
Last Resolved: 5 years ago4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 27

Updated

4 years ago
Status: RESOLVED → VERIFIED
status-firefox27: --- → verified

Comment 38

4 years ago
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.

Comment 40

4 years ago
(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

Updated

4 years ago
relnote-firefox: --- → ?

Updated

4 years ago
relnote-firefox: ? → 27+
You need to log in before you can comment on or make changes to this bug.