Show back button in menu bar if the phone uses end-to-end gesture support

[jonalmeida]

What is the user problem or growth opportunity you want to see solved?

On newer phones and up-to-date versions of Android, the system navigation bar is no longer there. Instead, you have Gesture Navigation that let's you swipe from the left/right of the screen to go back.

How do you know that this problem exists today? Why is this important?

While it is still functional with the forward button (in the enabled state), losing the ability to long press on the back button to show the page history.

Who will benefit from it?

Users that upgrade to Android 10+

In addition to fixing the problem, we would also gain the ability to give users visual feedback when you go back enough to reach the end of the page history, similar to being at the top of the history navigation where the forward button is disabled.

┆Issue is synchronized with this Jira Task

[jonalmeida]

@person808 may have a better idea on other options we could provide instead of my proposed solution.

[cadeyrn]

Show back button in menu bar if the phone uses end-to-end gesture support

I suggest to always show the back button and not only for phones with enabled gestures navigation, for two reasons:

• I disabled gestures navigation on my phone so I wouldn't see the back button in the menu. But I would benefit from this button as well because it would be much easier for me to reach this button. It's possible but difficult for me to reach the Android back button with only one hand.
• It would also be confusing in the Firefox support if sometimes there is a back button and sometimes not.

[person808]

The current UX is definitely awkward for Android 10. I know @brampitoyo and I settled on the current implementation so we could land the feature faster. Maybe he can weigh in on this.

[brampitoyo]

@person808 @jonalmeida Let’s keep thinking about this problem. My feeling is to agree with @cadeyrn: always showing the back button inside the main menu would benefit Android 10 users who aren’t able to swipe-and-hold.

(Unless there’s a way to detect swipe-and-hold somehow – I don’t think there is).

[brampitoyo]

This isn’t the most discoverable option, but I wonder whether we can detect long-press-then-swipe, and use it as a shortcut to open the history stack?

In other words:

• Swipe straight away: go back one page
• Long-press on edge: the history stack “peeks” from the screen edge
  • Swipe after long-press: show history stack

Here’s an example using Google’s own Play Store app:

[person808]

Maybe we would be able to do that? But I would be very hesitant about adding a gesture on top of a web page right now since the only one we had like that (pull-to-refresh) still has bugs.

[jonalmeida]

Maybe we would be able to do that? But I would be very hesitant about adding a gesture on top of a web page right now since the only one we had like that (pull-to-refresh) still has bugs.

The PTR issue is due to over-scroll detection. The long press handling may be different.

It would be interesting to know how other apps have added this gesture, if done manually. It seems to come free if you have a left drawer with a hamburger menu from a few minutes of testing that I did with apps that haven't been updated in a few years.

At the very least we would learn what issues we need to solve that block us from implementing it.

[brampitoyo]

It seems to come free if you have a left drawer with a hamburger menu

That’s interesting.

When I tested this feature, it seemed like there’s a clear-cut boundary between the two gestures.

This meant: if the swipe-back gesture is activated, there’s no way to invoke the long-press on edge. Thus, we avoid the problem of two gestures stacking on top of each other.

The swipe-45º gesture, which also works to open the hamburger menu, was a different case. Android seems to mix it up with swipe-back quite a lot; and in the end, I wasn’t able to reliably invoke swipe-45º.

What I worry about isn’t the conflict. It’s the discoverability. Had I not read articles that told me how to perform long-press on edge, I wouldn’t know that this gesture exists.

TL;DR – @jonalmeida’s comment 0 seems to be the most sensible move. Adding buttons is more reliable than adding gestures that are hard to discover and may overlap with other gestures in unpredictable ways (unless the user knows the trick).

[jonalmeida]

TL;DR – @jonalmeida’s comment 0 seems to be the most sensible move. Adding buttons is more reliable than adding gestures that are hard to discover and may overlap with other gestures in unpredictable ways (unless the user knows the trick).

@brampitoyo I would lean towards @cadeyrn 's recommendation which works on the initial ask. i.e. always show the back button instead of only showing based on the type of device support (gesture).

[brampitoyo]

@jonalmeida This sounds sensible to me.

One issue that we have to figure out, is the correct ordering for the menu item navbar.

Let’s say that we have space for 5–6 different icons. Going from left to right:

• Items 1 and 2 are pretty clear. They should be Back and Forward.
• Item 3 is less clear
  • If we mirror Firefox Desktop, this item should be Stop/Reload
• Item 4 can either be Bookmark or Share
• Item 5 can either be Bookmark, Share, or Stop/Reload
  • If we mirror the existing Fenix layout, this item should be Stop/Reload

Note the positioning of item 5. It’s “sticky” and always aligned to the side of the screen, so it’s important that we put a frequently used action here. Furthermore, if the main menu is double-tapped, you’ll instantly select this item. This bolsters the case that we should put the Stop/Reload action here.

For now, here’s my first take at the navbar ordering:

[ghost]

@brampitoyo I'd say that to not keep the Reload button after the forward button as users might click it accidentally while clicking the forward button (as thumb finger is large). keep the Reload button at the last position in the mock (#12926 (comment)) you gave. Pull to refresh gesture will handle the frequent tab Reload use case. Perhaps you may place the Share (or bookmark button for that matter) button in that place. As Chrome browser also places this button (Reload) in the last position as well; it's a correct place for that, users coming from other browsers also might expect expect that button to be in that same last place in Firefox as well.

[brampitoyo]

@FrostedIce339 Thanks for the feedback. Yes, we should consider putting Stop/Reload as the last position.

You wrote a few good reasons:

• If put too close to the Forward button, it could be accidentally triggered – although this shouldn’t happen if we follow Material Design’s recommended minimum touch target size (48x48dp)
• Chrome puts it there – so users who move to Firefox from Chrome might expect it there, too

Another reason may be because the buttons are grouped in a logical order:

1. Back & Forward
2. Save & Share ← (think of Bookmark as Save)
3. Reload

Putting Save & Share next to Back & Forward seems well-thought, not random or arbitrary.

[Imerion]

There really should be an option to have a back button displayed immediately in the menu bar, not in a submenu. It is the button I use most on my browser (yes, more often that the adress field) and any extra clicks before being able to use it will soon add up and feel inefficient. See browsers Brave and Vivaldi for good examples of how this could work and look.

[sv-ohorvath]

Verified as fixed on 80.0.0-beta6 on several devices:
Samsung Galaxy Tab S6 (Android 9), Sony Xperia Z5 Premium (Android 7.1.1), Motorola Moto G6 (Android 8), OnePlus A3 (Android 6.0.1), Google Pixel 3a (Android 10), Nexus 5 (Android 5.1) and Huawei Mate 20 Lite (Android 10)