Based on user requests for an option to disable gesture based features we should allow an easy way of toggling:
New toggles for the above features.
Strawman mockup - https://github.com/mozilla-mobile/fenix/issues/10240#issuecomment-647241235:
String resources - https://github.com/mozilla-mobile/fenix/issues/13442#issuecomment-682618440
Here are strings for all four gestures. Can you confirm that the first two will be what will be implemented? The ones from the mock are outdated.
- Pull to refresh
- Scroll to hide toolbar
- Swipe toolbar sideways to switch tabs
- Swipe toolbar up to open tabs
Users can easily find the settings to enable / disable gesture based features.
@ UX how should this be organized?
@Mugurell Would you be able to describe some of our user issues with pull to refresh and dynamic toolbar?
I assume that pull to refresh might interfere with certain site header, and dynamic toolbar would sometimes not minimise?
Basically:
And there are users that requested an option to disable these: https://github.com/mozilla-mobile/fenix/issues/8847, https://github.com/mozilla-mobile/fenix/issues/9719
@brampitoyo to follow-up
@Mugurell I donāt see this as a big issue for two reasons:
In the interest of customisability āĀ but being aware of feature creep āĀ if thereās sufficient interest and problem to address, Iād consider adding those options under Settings.
It makes sense, as written on https://github.com/mozilla-mobile/fenix/issues/8847#issuecomment-601115291, to āadd this setting below the one that let you choose if you want the toolbar at the top or at the bottomā.
I also think that we should put it under the āCustomiseā sub-page.
@betsymi do you have any opinion on:
Posting a strawman mockup of what the gesture settings may look like under the āCustomizeā Settings sub-page. CC @betsymi.
This looks really good Bram! I like breaking out gestures into their own heading which fixes a problem I saw with information hierarchy in pr #11678. The pr made it look like scrolling the toolbar only applied to the bottom toolbar. Should we tweak the wording a little? Down is used to describe two different gestures. Pull down to reload sites
the user gesture is tap-hold and drag down. Scroll down to hide toolbar
the user gesture is tap-hold and drag up. How about Scroll to hide address bar
?
Any progress on this issue? When will the option for disabling the scroll down to hide toolbar be added?
The pull request adds text strings. The project is in a string freeze for a while. Until the freeze is lifted the pull request is not eligible to land. In addition it requires some changes to bring it into line with what Bram showed.
Thanks @kbrosnan. For the string change, I will ask @betsymi to comment on these.
@betsymi Hey, Any update on this issue?
@brampitoyo Here's copy to add to the Customize screen for these gestures.
Umm, when will option to unhide toolbar when scrolling be added?
Also the first gesture dosen't seem to work!
@paritosh9199 this issue is open. The feature has not been added to Fenix yet. It will not work until we add code to add this feature in Fenix.
@kbrosnan Any ETA for that option to be added?
I've run into a few sites where the url bar doesn't hide which covers content. Would love to turn auto-hiding off.
Thank you all for pushing this!
Seems like we have everything we need to start get this going.
@fredboy I know you worked on a draft PR for this.
Would you be interested in finishing the implementation based on the new specs?
@Mugurell Is someone working on this?
@brampitoyo @betsymi We also have swipe to switch tabs and I'll be putting up a PR for swiping up to open the tab tray soon. I think we'll probably want to have settings for these too since they are triggered right above the system gesture area when the toolbar is on the bottom. Also not sure if this is relevant for this, but the swipe to open tab tray gesture will only be active for the bottom toolbar (at least thats the current plan)
Both of these will be behind feature flags for testing purposes as well.
Thanks for posting this! I would so very much like to have options for disabling pull down reload (this screws things up for me all the time - most stupid hidden UI function ever) and even more importantly: an option to always show the menu bar. I (accidentally) posted a duplicate of this, with a few more arguments:
What is the user problem or growth opportunity you want to see solved?
Always having the menu bar visible to quickly allow navigation or access to browser functions without the need to keep doing random up/down movements would be desirable.
How do you know that this problem exists today? Why is this important?
This function used to be included in the options menu but I can't seem to find it anymore in the 79+ series. Hiding important UI elements is a huge problem with modern UI design. There is no need to keep hiding things. Smartphone screens are very large today, and something that really isn't needed is more vertical space. Hiding this small menu bar makes no sense and makes efficient browsing impossible.
Who will benefit from it?
Anyone who prefers to have the UI ready whenever needed and prefers a more efficient way to navigate and control their browser.
@Mugurell Is someone working on this?
Since we have all thats's needed for pull to refresh and toolbars I staged this for the next Sprint.
Since we're still waiting for UX for the new tabs swiping gestures I've created https://github.com/mozilla-mobile/fenix/issues/13442 to add new toggles for these features when the UX is ready.
@Mugurell Weāre going to chat about the right way to call these gesture settings tomorrow. After the discussion, I expect that we will have a better idea of what to call each menu item, post in this issue, and unblock you. Stay tuned.
@brampitoyo Any update regarding the strings?
@Mugurell I will assign this to @betsymi.
Question about process: @betsymi do you have a board or something where we can prioritize these against other issues? I know you're incredibly busy with each team, so if there's anything that we can do to help you prioritize.
Copying betsymi's response from https://github.com/mozilla-mobile/fenix/issues/13442#issuecomment-682618440
Here are strings for all four gestures. Can you confirm that the first two will be what will be implemented? The ones from the mock are outdated.
- Pull to refresh
- Scroll to hide toolbar
- Swipe toolbar sideways to switch tabs
- Swipe toolbar up to open tabs
@betsymi
I see the third option's title being a bit long and so continuing on a second line when in portrait. Is it ok?
@betsymi
I see the third option's title being a bit long and so continuing on a second line when in portrait. Is it ok?
We can shorten the third option to read Swipe toolbar to switch tabs
According to the original issue, eventually there will also be a Swipe toolbar up to show open tabs
, which would suggest Swipe toolbar to switch tabs
won't make sense without the sideways
.
According to the original issue, eventually there will also be a
Swipe toolbar up to show open tabs
, which would suggestSwipe toolbar to switch tabs
won't make sense without thesideways
.
Yes, good point. Let's leave the strings as-is then.
Filed an issue to disable the gesture features in the tab tray: https://github.com/mozilla-mobile/fenix/issues/14911.
According to the original issue, eventually there will also be a
Swipe toolbar up to show open tabs
, which would suggestSwipe toolbar to switch tabs
won't make sense without thesideways
.
Do you know of the issue for this? Please link if you know where that is being discussed
According to the original issue, eventually there will also be a
Swipe toolbar up to show open tabs
, which would suggestSwipe toolbar to switch tabs
won't make sense without thesideways
.Do you know of the issue for this? Please link if you know where that is being discussed
It's mentioned in the first comment on this ticket.
Swipe toolbar up to show open tabs
is to be added in https://github.com/mozilla-mobile/fenix/issues/11862
This ticket already got verified by @cadeyrn (thanks!) who found
Verified on Nightly 9/10 on different devices and besides the already filled issues, I didn't find anything new. I'll close this as fixed.
Devices:
Pixel 4 (Android 10)
Nexus 9 (Android 7.1)
HTC Desire 820 (Android 6.0.1)
The url bar seems to autohide even after disabling autohide on scroll in settings.
Device: OnePlus 7
Nightly 200910 06:07 (Build #2015763059)
AC: 58.0.20200908130811, 52ac53ba1
GV: 82.0a1-20200907094115
AS: 61.0.13
@paritosh9199 That was already mentioned here: https://github.com/mozilla-mobile/fenix/issues/10240#issuecomment-690039701
Thanks for checking!
Scroll to hide toolbar only works for top bar, not bottom bar.
@andreicristianpetcu see #14902
@andreicristianpetcu That is odd. How come? I really prefer the bottom bar since it is possible to reach without using both hands, but I really want it to stay there at all times and not hide.
@lmerion I expect it to work the same for both top and bottom. Top works, bottom has a bug mentioned above your comment.
@andreicristianpetcu Ah, I see! Sorry! I was a bit to quick there and missed the post with the bug. I thought the behaviour was intentional.
Good work. Nightly firefox now feels like a proper, respectable browser, not the toy the live version feels like.
Issues related to the static bottom toolbar after this:
Sorry if I'm not following what is happening here. This worked perfectly for me in the last beta (Blackberry KeyOne, Android 8.1) and made browsing so much smoother and more efficient, but in the latest beta the options are gone again. Is this just a temporary removal to fix bugs or what is happening?
@Imerion see https://github.com/mozilla-mobile/fenix/releases/tag/v81.1.1-beta.4:
Disables gestures controls (which had some problems in Nightly) #15005
@cadeyrn Ok, so they will be brought back once those issues are fixed? Because i really believe these options are necessary for usability and accessability reasons.
Most helpful comment
Posting a strawman mockup of what the gesture settings may look like under the āCustomizeā Settings sub-page. CC @betsymi.