Closed
Bug 1162150
Opened 10 years ago
Closed 6 years ago
Experiment with "pull-to-refresh" in fennec
Categories
(Firefox for Android Graveyard :: General, enhancement, P3)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: antlam, Unassigned)
References
Details
(Keywords: parity-chrome, Whiteboard: [pwa-front-end])
Related to bug 1014335
Martyn and I chatted a bit about what this might look like "app wide" so we should have a go at some proof of concepts if we get the chance.
Reporter | ||
Updated•10 years ago
|
Flags: needinfo?(mhaigh)
Comment 1•9 years ago
|
||
I don't think this is a great idea as it's going to be really difficult for us to work out when the page stops and when this functionality should kick in
Flags: needinfo?(mhaigh)
Comment 2•9 years ago
|
||
By "app wide" I assume you mean for webpages.
I thought there was an older bug filed about this but I can't find it. This does seem like it would be challenging from a platform perspective.
Flags: needinfo?(snorp)
Flags: needinfo?(mark.finkle)
Reporter | ||
Comment 3•9 years ago
|
||
(In reply to :Margaret Leibovic from comment #2)
>This does seem like it would be challenging from a platform perspective.
Agree. My main UX concern is that we'd collide with some websites/web-apps pull-to-refresh interaction as well. So we'd have to really try a couple approaches here.
Comment 4•9 years ago
|
||
We also already have code that makes the toolbar appear when we hit the bottom of the webpage. Just another source of conflict if we add any other change.
Flags: needinfo?(mark.finkle)
Comment 5•9 years ago
|
||
(In reply to Mark Finkle (:mfinkle) from comment #4)
> We also already have code that makes the toolbar appear when we hit the
> bottom of the webpage. Just another source of conflict if we add any other
> change.
Bug 973727
We could pretty easily do this with some work in APZ, but I personally hate this feature in Chrome, so we'd have to somehow do better.
We could also probably do this without APZ work since we know in the java bits when we are overscrolling in order to draw the glow.
Flags: needinfo?(snorp)
Reporter | ||
Comment 7•9 years ago
|
||
(In reply to Mark Finkle (:mfinkle) from comment #5)
> (In reply to Mark Finkle (:mfinkle) from comment #4)
> > We also already have code that makes the toolbar appear when we hit the
> > bottom of the webpage. Just another source of conflict if we add any other
> > change.
>
> Bug 973727
Yeah, I really like this logic! but it's not often I trigger it. I assume this is is because I always scroll back as soon as I see a hint of the websites footer coming into view.
Cant this be made to be triggered like other android apps?
Only when you scroll up to the top of the page and once the AwesomeBar appear's - then the pull to refresh option/icon should be available?
Also there could be a kill switch in settings to enable or disable this?
Comment 12•8 years ago
|
||
Last discussion here is from 2015. Now APZ is landed and pull-to-reload is pretty common on Android. Could pull-to-refresh be revisited?
Firefox has always been pretty good when it comes to OS look'n'feel integration, but here - on Android - it fails. Most Android apps have pull-to-refresh including Chrome. Other users also requesting this feature: https://www.reddit.com/r/firefox/comments/4ei111/pull_down_to_refresh_on_android/
I personally find it annoying that I have to Point-Touch-Menu + Point-Touch-Reload whereas I could also more sloppily swipe-down to reload. Have to do this all the time when revisiting Hacker News or my favorite sports website. Actually it's the most "very noticable" feature missing compared to Chrome.
I'm a nightly user. Maybe this could be configurable and maybe on Nightly you might also do some A/B testing (though I would personally just stick with Android's default UX instead of making up my own UX)
Keep up the good work. APZ is terrific :)
Comment 14•8 years ago
|
||
Is this something users request?
My gut feeling is that this is a very prominent gesture for something that might not be a primary feature of a browser (refresh). But I defer this to the product and UX teams to decide (and prioritize / add to roadmap).
Flags: needinfo?(s.kaspari)
Flags: needinfo?(bbermes)
Flags: needinfo?(alam)
Comment 15•8 years ago
|
||
Would be nice to include this (as part of the Photon work), especially if it's a common gesture in many other apps.
I vote for it.
antlam?
Flags: needinfo?(bbermes)
Comment 16•8 years ago
|
||
I'd love to see this happen!
Twitter, Chrome all have this!
Also please include an option to enable/disable this feature.
Comment 17•8 years ago
|
||
For reference, here the Material guidelines for "Swipe to refresh":
https://material.io/guidelines/patterns/swipe-to-refresh.html
(In reply to bull500 from comment #16)
> Twitter, Chrome all have this!
For most apps, like Twitter (Chrome excluded), it makes sense logically: New content appears at the top and so you scroll up to see new content and eventually you "overscroll" to load new content. For a browser/website this doesn't make sense necessarily. But I guess since Chrome has it a lot of users are expecting it now.
Comment 18•8 years ago
|
||
(In reply to Sebastian Kaspari (:sebastian) from comment #17)
> For reference, here the Material guidelines for "Swipe to refresh":
> https://material.io/guidelines/patterns/swipe-to-refresh.html
>
> (In reply to bull500 from comment #16)
> > Twitter, Chrome all have this!
>
> For most apps, like Twitter (Chrome excluded), it makes sense logically: New
> content appears at the top and so you scroll up to see new content and
> eventually you "overscroll" to load new content. For a browser/website this
> doesn't make sense necessarily. But I guess since Chrome has it a lot of
> users are expecting it now.
Hey! Yeah that's totally true but with all these huge screen/sized phones doing a refresh kinda involves changing your hand/phone position to reach for the hamburger menu and click the buttons.
Will pull to refresh, I can easily scroll to the top and then execute the action.
Reporter | ||
Updated•8 years ago
|
Flags: needinfo?(alam)
Reporter | ||
Comment 19•8 years ago
|
||
(In reply to Sebastian Kaspari (:sebastian) from comment #14)
> Is this something users request?
>
> My gut feeling is that this is a very prominent gesture for something that
> might not be a primary feature of a browser (refresh). But I defer this to
> the product and UX teams to decide (and prioritize / add to roadmap).
(In reply to Barbara Bermes [:barbara] - NI please! from comment #15)
> Would be nice to include this (as part of the Photon work), especially if
> it's a common gesture in many other apps.
>
> I vote for it.
>
> antlam?
Maybe something to consider for V2 of photon. V1 is going to be visual changes only.
I think this also has a nice parallel with some of the single-hand use type of conversations we've been having so I'm going to NI jack here to think about it some more!
Flags: needinfo?(jalin)
Comment 21•8 years ago
|
||
Would be easier to only keep blocking bugs on that meta, cheers
No longer blocks: 1285858
Comment 23•8 years ago
|
||
(In reply to Sebastian Kaspari (:sebastian) from comment #14)
> Is this something users request?
>
Yes please. It's the one feature of Chrome that I miss.
Comment 24•7 years ago
|
||
Installed progressive web apps would also benefit from this, as they don't have any browser UI when in standalone or fullscreen mode.
Updated•7 years ago
|
Blocks: progressive-apps
Comment 25•7 years ago
|
||
I vote against pull-to-refresh. I frequently do this gesture to show android notifications and "mini-settings". I always turn this feature off in Chrome and Opera. If you do implement it, please give us a way to disable.
Comment 26•7 years ago
|
||
(In reply to Ken Riley from comment #25)
All I know is: can't you be more careful and just put your fingers on the notification bar at the top of your screen, and not on the application running below it, when you do your gesture?
Flags: needinfo?(sandken)
Comment 27•7 years ago
|
||
Nope. I have palsy and use a stylus. If this feature is implemented, I'd like a config option to
disable it (the same as Chrome and Opera). One of the things I like about Firefox is that it's so configurable.
Flags: needinfo?(sandken)
Comment 28•7 years ago
|
||
Please add this feature. I've been begging for this feature for years now - truthfully, it's the only thing holding me back from using Firefox for Android full time, and now Photon looks too good to miss out on. I refresh pages a lot, specifically when I enable desktop mode or if I'm testing my websites. Besides that, the refresh button is entirely too awkward to navigate to. We absolutely need this feature, and soon.
(In reply to Anthony Lam (:antlam) from comment #19)
> Maybe something to consider for V2 of photon. V1 is going to be visual
> changes only.
Please, please no. This feature has been too long overdue to begin with (this bug is over two years old, and this has been a problem for quite a lot longer than that). If it's absolutely necessary to keep this out of V1 Photon for version control purposes, then a patch (or something of the sort) would be extremely valuable for users that need this feature. If need be, I can build the .apk from source with the changes applied. Plus, it would allow us to provide feedback on the feature, so that when it is ready for V2, most issues will have already been addressed.
That's my two cents. I really hope this gets more attention.
Updated•7 years ago
|
Whiteboard: [pwa-front-end]
Comment 30•7 years ago
|
||
Not to do a +1 but I had a chat with an user yesterday and I understand why this can be a blocker when moving from Chrome on Android to Firefox.
Whiteboard: [pwa-front-end] → [pwa-front-end][Chrome-parity]
Updated•7 years ago
|
Severity: normal → enhancement
Comment 31•7 years ago
|
||
I'd like us to move forward with this (for normal browsing, PWA and Custom Tabs), so we can get initial feedback.
Snorp, I believe there is already an experimental implementation somewhere — when do you think this can land in Nightly (behind a flag)?
Flags: needinfo?(snorp)
Reporter | ||
Comment 32•7 years ago
|
||
If we need a pref to stick this behind, I think it should go under General, or maybe even Accessibility.
But we definitely want Michelle to chime in here for some help with the pref labels and communication here.
Reporter | ||
Comment 33•7 years ago
|
||
Nevermind, spoke too soon, not Accessibility.
Comment 34•7 years ago
|
||
for this to work, front end need to know
1. What's the api for refreshing a page? In BrowserApp it's [1]. I think it's different in GeckoView implementation.
2. When to hide the loading animation when page load is done? Something like WebView's onPageFinished call back [2]
[1]https://searchfox.org/mozilla-central/rev/8839daefd69087d7ac2655b72790d3a25b6a815c/mobile/android/base/java/org/mozilla/gecko/Tab.java#578
[2] https://developer.android.com/reference/android/webkit/WebViewClient.html#onPageFinished(android.webkit.WebView,%20java.lang.String)
Eugen has played with this before and I think he can give you steps on how to accomplish this with GV.
Flags: needinfo?(snorp) → needinfo?(esawin)
Comment 36•7 years ago
|
||
For GeckoView:
1. GeckoSession.reload() reloads the page.
2. ScrollListener.onScrollChanged() can be used to determine content scroll position.
3. ProgressListener.onPageStop() signals finished page load.
Here is and basic example implementation (using a timeout, not onPageStop): https://github.com/eamsen/gecko-dev/commit/b2294d417275b2324f0e4da0220237f716f336f8
Flags: needinfo?(esawin)
Comment 38•7 years ago
|
||
Just FYI there is now a pull to refresh add on for Android
https://addons.mozilla.org/en-US/firefox/addon/pull-to-refresh/?src=search
it does the job but I would much prefer a native solution with an animated swirly arrow like in History -> Synced Devices ;)
Comment 39•7 years ago
|
||
Thanks for the tip. Seems to work, although the operation is a bit naff as you say.
Comment 40•7 years ago
|
||
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome
Whiteboard: [pwa-front-end][Chrome-parity] → [pwa-front-end]
Comment 41•6 years ago
|
||
I built an extension that does just this :) https://addons.mozilla.org/en-US/firefox/addon/firefox-pull-to-refresh/
Updated•6 years ago
|
Comment 42•6 years ago
|
||
WONTFIX because we will implement pull-to-refresh in Fenix, not Fennec.
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(jalin)
Resolution: --- → WONTFIX
Assignee | ||
Updated•4 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•