Closed Bug 1162150 Opened 9 years ago Closed 6 years ago

Experiment with "pull-to-refresh" in fennec

Categories

(Firefox for Android Graveyard :: General, enhancement, P3)

All
Android
enhancement

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.
Flags: needinfo?(mhaigh)
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)
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)
(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.
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)
(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)
(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?
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 :)
Can we get this into our radar?
Flags: needinfo?(s.kaspari)
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)
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)
I'd love to see this happen! Twitter, Chrome all have this! Also please include an option to enable/disable this feature.
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.
(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.
Flags: needinfo?(alam)
(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)
Blocks: 1285858
Priority: -- → P2
Would be easier to only keep blocking bugs on that meta, cheers
No longer blocks: 1285858
(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.
Installed progressive web apps would also benefit from this, as they don't have any browser UI when in standalone or fullscreen mode.
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.
(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)
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)
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.
Whiteboard: [pwa-front-end]
set to P3 per discussion with Andreas.
Priority: P2 → P3
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]
Severity: normal → enhancement
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)
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.
Nevermind, spoke too soon, not Accessibility.
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)
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)
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 ;)
Thanks for the tip. Seems to work, although the operation is a bit naff as you say.
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]

WONTFIX because we will implement pull-to-refresh in Fenix, not Fennec.

Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(jalin)
Resolution: --- → WONTFIX
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.