-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Allow users disabling gesture based features #10240
Comments
@ 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: #8847, #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. Toolbar auto-hideIt makes sense, as written on #8847 (comment), to ”add this setting below the one that let you choose if you want the toolbar at the top or at the bottom“. Pull-to-refreshI 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. |
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. |
It's mentioned in the first comment on this ticket. |
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. |
The url bar seems to autohide even after disabling autohide on scroll in settings. Device: OnePlus 7 |
@paritosh9199 That was already mentioned here: #10240 (comment) |
Scroll to hide toolbar only works for top bar, not bottom bar. |
@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: |
… based features" This reverts commit d8d896c.
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:
|
@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. |
Why/User Benefit/User Problem
Based on user requests for an option to disable gesture based features we should allow an easy way of toggling:
What/Requirements
New toggles for the above features.
![](https://user-images.githubusercontent.com/51007/85244431-c0268500-b498-11ea-87d0-c53f08957bf7.png)
Strawman mockup - #10240 (comment):
String resources - #13442 (comment)
Acceptance Criteria (how do I know when I’m done?)
Users can easily find the settings to enable / disable gesture based features.
┆Issue is synchronized with this Jira Task
The text was updated successfully, but these errors were encountered: