Swipe up the bottom bar to see the tab menu #11862
Comments
|
This will conflict with A10 gestures. |
Actually I don't think so. There will be no problem with gestures. I've tried swipe up bottom bar with highest sensivity and doesn't conflict with gestures. |
person808
added
Feature:Gesture
feature request 🌟
|
I'll link this issue in #176 since I can't find an older issue requesting this. There is some discussion in #176 of potential issues with Android 10 gestures interfering with swiping up at the bottom of the screen, but nothing definitive. Will wait for UX feedback to determine if this is a gesture we want to add and if the Android 10 gestures will be a problem. |
|
Assigning to @topotropic for UX feedback |
|
An option could be a toggle in the settings to switch this on or off. |
When I was on android 9 I loved that quick swipe up gesture which was showing some options of the 3 dot menu...but later on they removed saying this conflicts with A10 gestures...I vote for bringing back the feature with a toggle to turn on/off...default should be off. |
|
If the bottom bar is slightly taller, I don't think it would be in conflict with A10 gestures. |
|
I vote for this feature, too. I still find it confusing that I can swipe it down, but not up |
|
The closed tray should also be visible as it used to be in the early days of Fenix, for better discovability. |
|
#12174 would add the much of the support necessary to allow this to be done from an engineering perspective. If UX gives the go-ahead I can work on this. Question for UX if we do decide to implement this: would this only available for the bottom bar? |
|
@topotropic to follow-up |
@person808 I'd be curious to learn how much work is involved here - if the foundations are there and it's a rather quick thing to do, I'd be curious to try it out and see in how much it collides with A11 gestures. If we implement it, it would be just for bottom bar, yes. Thanks! |
|
Once the PR I mentioned gets merged. I'll try to implement a version of this. |
AmyYLee
removed
needs:UX-feedback
Would a screen wide swipe up gesture conflict with bringing back the ability to swipe up on the 3 dot menu? If so, maybe an alternative is to have the gesture be to swipe up from the tab button instead of the entire bottom bar? |
|
@topotropic @person808 The thing is this issue was I think filed keeping in mind with the 3 button Android navigation layout but it doesn't consider that most of the devices are now switching to gestures navigation by default and I think this is way Google's Android development team wants to go with. Gestures will become very common on Android no matter how much we resist. Of course. there are a lot of use cases for 3 button Android navigation layout and that's reason why they still kept on Android and made mandatory by its CDD documentation. But the fact remains that if we add this sort of feature it'll trigger the Android app multitasking gesture (recents app switcher). There's a very tiny space left between the Fenix and Android gesture navigation pill (see the Screenshot¹) and some (read a lot) Android OEMs hide that pill button altogether (see the Screenshot²) making it even harder to not trigger the Android recents app switcher gesture instead of what this issue wants to trigger. So you either implement such gestures in 3 button Android layout or don't enable them on Gesture navigation layout. However, if you still insist on adding this gesture then I'd say at least suggest to add a divider line between Fenix's address bar and the Android's gesture navigation pill bar so that it at least becomes easy to spot where the Fenix's address bar is or Fenix's window itself is ending and where the Android's gesture navigation pill bar is starting, so that users can correctly aim for the Fenix's address bar when it's at the bottom. This is something that Chromium browser already do. I am going to file a new issue for that in a moment and let you know. Update: Here's the issue: #12882 Screenshot¹:
|
ghost
mentioned this issue
kbrosnan
changed the title
…tom toolbar. - Create a new gestures package for classes that implement gestures that work on multiple screens - Move SwipeGestureLayout to the gestures package - Rename ToolbarGestureHandler to SwitchTabsGestureListener - Gate swipe to show tab tray behind the same feature flag as swipe to switch tabs - Update home fragment snackbars to explicitly pass a CoordinatorLayout as the view to attach them to - Extract common gesture function into utility file.
…tom toolbar. - Create a new gestures package for classes that implement gestures that work on multiple screens - Move SwipeGestureLayout to the gestures package - Rename ToolbarGestureHandler to SwitchTabsGestureListener - Gate swipe to show tab tray behind the same feature flag as swipe to switch tabs - Update home fragment snackbars to explicitly pass a CoordinatorLayout as the view to attach them to - Extract common gesture function into utility file.
|
You're not supposed to do this, I already filed this last year #1021 Also, even if Android didn't have gesture nav at all, the fatal flaw of this "swipe-up-bottom-bar" idea is that for people that use their phones with one hand (and that's even more likely for users that have opted for bottom toolbar), you keep accidentally swiping up the UI when you're just trying to scroll down a webpage. It's a UX nightmare and no offence but I'm surprised this even made it so far. If you're determined to ship this, you have to make it optional because of the accidental swipe-ups when users are just trying to scroll. |
All gestures will be optional. #10240. |
…tom toolbar. - Create a new gestures package for classes that implement gestures that work on multiple screens - Move SwipeGestureLayout to the gestures package - Rename ToolbarGestureHandler to SwitchTabsGestureListener - Gate swipe to show tab tray behind the same feature flag as swipe to switch tabs - Update home fragment snackbars to explicitly pass a CoordinatorLayout as the view to attach them to - Extract common gesture function into utility file.
…tom toolbar. - Create a new gestures package for classes that implement gestures that work on multiple screens - Move SwipeGestureLayout to the gestures package - Rename ToolbarGestureHandler to SwitchTabsGestureListener - Gate swipe to show tab tray behind a feature flag - Update home fragment snackbars to explicitly pass a CoordinatorLayout as the view to attach them to - Extract common gesture function into utility file. fix conflicts imports
…tom toolbar. - Create a new gestures package for classes that implement gestures that work on multiple screens - Move SwipeGestureLayout to the gestures package - Rename ToolbarGestureHandler to SwitchTabsGestureListener - Gate swipe to show tab tray behind a feature flag - Update home fragment snackbars to explicitly pass a CoordinatorLayout as the view to attach them to - Extract common gesture function into utility file.
…tom toolbar. - Create a new gestures package for classes that implement gestures that work on multiple screens - Move SwipeGestureLayout to the gestures package - Rename ToolbarGestureHandler to SwitchTabsGestureListener - Gate swipe to show tab tray behind a feature flag - Update home fragment snackbars to explicitly pass a CoordinatorLayout as the view to attach them to - Extract common gesture function into utility file.
|
I think this video looks good. https://www.reddit.com/r/firefox/comments/islbb9/added_some_flair_to_firefox_for_android_and_some/ |
|
Looks good. Hope for same, but for top positioned address bar. With swipe down and panel atop. Can't use it on bottom. Easy too far. |
|
When this going to be implemented? Firefox is impossible to use left hand. Tab button is located on opposite side of the screen. This swipe was needed to be there on day 1. |
Swipe-up is not the correct solution for this, the correct solution is a "left-handed" option in the settings. It's crazy that "left-handed" options are still so rare :( |
Chrome deals it with swipe down very well. And New Tab (+) button is located in the top-left corner. For left hand usage top panel is more suitable, as bottom is hard to reach. |
Most people keep using navigation buttons, as they are more convenient. A10 navigation gestures are not popular. Too complicated. So as most manufacturers. Samsung, Huawei, Xiaomi, Oppo, Realme, vivo etc. All have navigation buttons by default. And many programs do have swipe from top gesture for some own functionality, despite the fact that there is a system swipe from top edge to open notification panel. There has never been problem with that. It's totally same. Yet i'm personally using top panel in Firefox, as it's far easier to reach top with thumb finger. |
|
What? Gesture will undoubtedly become the norm if they aren't yet. If they were not popular, manufacturer would not have copied them from Apple and if it was too complicated, Apple wouldn't use them. I do agree with the counter point to this issue. There is a possible gesture conflict. |
|
All gestures should be optional!! I hope next version can use it. |
|
Another year gone...
Almost every Chrome clone has this feature and there is no any conflict with status bar swipe.
Still very niche. Those A10 swipes are very complicated and will always stay geeky. |
|
Moved to bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1807051 Change performed by the Move to Bugzilla add-on. |
What is the user problem or growth opportunity you want to see solved?
I like the new design but it it feels inconsistent. If you can swipe down to close the menu why can't you swipe up to open it?
How do you know that this problem exists today? Why is this important?
It would make the app easier to use because you won't have to aim for the tab button and it would feel more natural with the gestures.
Who will benefit from it?
Better accessibly for left handed people
┆Issue is synchronized with this Jira Task
The text was updated successfully, but these errors were encountered: