[Spike] Holding back does not show tab stack history

[yoasif]

Acceptance Criteria

• Make an MVP prototype where user can jump to a specific spot in tab history (may involve adding the back button back) or have some recommendations about what eng restrictions there are
• timebox this to 2 days
• Use a feature flag (and don't land any strings until 7/18)

Steps to reproduce

1. Open a page with links
2. Click a link
3. Click a link
4. Hold back button

Expected behavior

Menu appears with tab history, allowing me to navigate back to the page in step 1 above.

Actual behavior

Holding back does nothing.

Device information

• Android device: Pixel 2
• Fenix version: 1.0.1912 (Build #10760203 🦎 67.0a1-20190312095443)

┆Issue is synchronized with this Jira Task

[cpeterso]

I think this history UI will need the GV "history stack" API that should land before the end of M3 (March): https://bugzilla.mozilla.org/show_bug.cgi?id=1509110

[Amejia481]

This is what happens when you hold press back button on Fennec

[gurpreetatwal]

Is this feature still planned to be included?

[NotWoods]

It's in the backlog

[danielzgtg]

@kbrosnan This won't work with Android 10 gesture navigation. The system considers a held back gesture as the same thing as a normal back.

#8083 (comment)

How about we make long-press forward show both forward and back tab history?

[buttercookie42]

Given that Chrome only relatively recently implemented the "show tab history when long-pressing the back button" behaviour, what do they do in that case?
And can't the classic back button behaviour still be implemented in any case when gesture navigation isn't enabled (or straight out not available on older devices)?

[danielzgtg]

It doesn't work in Chrome. They still need to add tab history for gesture navigation.

Yes, the classic back button behavior can and should be implemented. I meant “This won't work […]” to be in response to the other issue being closed.

[madb1lly]

Since I've been using Fenix Nightly as a daily driver I find the lack of this feature frustrating (and the complementary long press on the forward icon in the menu).

[Poopooracoocoo]

Focus issue: mozilla-mobile/focus-android#3845

[robsmith11]

Will the back history be added before Fenix replaces Fennec as the stable release?

It's a pretty significant functionality feature that is missing and doesn't seem to be on any milestone lists.

[kevincox]

Yup, this is a critical feature when you get websites that loop on back. Without a way to jump multiple pages at a time thee is no way to escape other than closing the tab.

[brampitoyo]

@pocmo @jonalmeida @person808 I’ve found something interesting earlier today. It’s a Chrome flag which shows a history stack on a swipe-and-hold gesture.

This was exactly the behaviour I recommended on #1048 (comment). My spec said that it should work when Gesture Navigation is ON. Unfortunately, Gesture Navigation is precisely what’s preventing swipe-and-hold to work!

Steps to reproduce:

• Set gestures to 2-button navigation
• Open Chrome
• Type chrome://flags
• Set overscroll-history-navigation to Enabled Navigation sheet
• Relaunch Chrome
• In one tab, open a set of pages in succession
• Swipe from the left, then hold

[Shaurya-Kalia]

Assigning it to a gesture is not the best solution in my view since different android versions and skins have different gesture implementations. The best way to go about it would be to have a dedicated back/forward buttons

[madb1lly]

Hi all,

Aren't there some configuration settings in Android which can be queried to determine the hardware UI which is being used? This would make it less vague then basing it on Android versions. The hardware UI setting would then determine whether the extra back button in the main menu or the swipe and hold gesture is provided.

E.g., in my case with a Nokia 8, it has hardware capacitative buttons so I don't need either the extra back button or the swipe and hold gesture (the latter wouldn't work anyway).

Cheers 🙂

[cadeyrn]

@madb1lly see #12926 (comment). The back button in the menu is not only useful for people with enabled gestures navigation.

[jonalmeida]

@brampitoyo that's pretty interesting (and an unfortunate case for Chrome)!

Based on other comments about potential conflicts with gesture navigation on different Android flavours like Samsung's TouchWiz, I wonder if we can take a page from Opera Touch and create a "gesture mode" that enables all these features by user choice as we build up more gestures that we would like to support. I don't usually support "add a setting for x" as a solution, because it can lead to clutter in the settings app and lots of divide on the state of a user's browser as we develop other features that can have conflicts depending on the on/off state. In this case however, we've seen conflicts with Android's new gesture mode for swipe to switch tabs as well, so it might be worth considering we're looking to invest into more gesture navigations.

While that's quite a grandiose idea, we could possibly just start with an onboarding card to begin with (similar to our dark/light theme card) for the two gestures we currently have? That might make them more discoverable.

Just throwing some ideas out there. :)

[brampitoyo]

Hearing more suggestions from all of you @Shaurya-Kalia @madb1lly @cadeyrn @jonalmeida made me believe that a permanent back button sounds like the most sensible idea to pursue in the short-term.

• Even if we have gestures compatible with many versions of Android, different skins could simply choose not to respect it.
• We can’t expect all phones to come with hardware or software back buttons, but if they do have it, can we still respect the tap-and-hold gesture?
• Doing hardware/software detection to disable/enable features sound like it could lead to more difficult maintenance and more corner cases.
• This time, we decided not to implement any gesture to access the history stack. However, for every new gesture we implement in the future, we should expose and make them controllable from within Settings.

[person808]

Doing hardware/software detection to disable/enable features sound like it could lead to more difficult maintenance and more corner cases.

100% agree. Its not as simple as doing something like isSystemGesturesEnabled() (I wish it was). We can use WindowInsets to detect the area reserved for system gestures, but that API comes with its own quirks.

As an engineering side note: If we do want to go down the route of adding fancier gestures, we might be able to extend/use SwipeGestureLayout. This provides the swipe detection for swiping to switch tabs, but its actually set up so it can detect swipes anywhere on the browser screen.

[yoasif]

• We can’t expect all phones to come with hardware or software back buttons, but if they do have it, can we still respect the tap-and-hold gesture?

@brampitoyo We just added it - are we really talking about possibly unsupporting it already, or am I misinterpreting this comment?

[M86xKC]

There are many other options, but most are not as discoverable as long-pressing on a back button.

Here are some Ideas:

1. Long-pressing the tab icon (next to the address) already shows (New tab, Net private tab then close bar), so maybe add it to the list there as back history ?. (most discoverable IMO)

2. Long-pressing the three dot does nothing as of now, so that can also be used (not discoverable).

3. Using gestures, as @person808 said there could be an option to swipe vertically on the address bar (up/down depending on where you have placed the address bar) to access the history stack. Maybe add a little bit of delay (more like swipe and hold) to prevent accidentally triggering it while scrolling.

[Dunexus]

3. Using gestures, as @person808 said there could be an option to swipe vertically on the address bar (up/down depending on where you have placed the address bar) to access the history stack. Maybe add a little bit of delay (more like swipe and hold) to prevent accidentally triggering it while scrolling.

This gesture is currently considered to be used to open tab tray, see #11862

[madb1lly]

• We can’t expect all phones to come with hardware or software back buttons, but if they do have it, can we still respect the tap-and-hold gesture?

@brampitoyo We just added it - are we really talking about possibly unsupporting it already, or am I misinterpreting this comment?
Hi @brampitoyo and @yoasif,

I'm not exactly sure what is meant by the "tap-and-hold" gesture yet I hope that the conclusion is to keep the long-press on any back button to show the history stack, whether that be an existing back hardware button or a new back button in the menu.

Cheers 🙂

[jonalmeida]

• We can’t expect all phones to come with hardware or software back buttons, but if they do have it, can we still respect the tap-and-hold gesture?

@brampitoyo We just added it - are we really talking about possibly unsupporting it already, or am I misinterpreting this comment?
Hi @brampitoyo and @yoasif,

I'm not exactly sure what is meant by the "tap-and-hold" gesture yet I hope that the conclusion is to keep the long-press on any back button to show the history stack, whether that be an existing back hardware button or a new back button in the menu.

Cheers 🙂

I believe @brampitoyo is referring to this tap-to-hold gesture from a related ticket: #12926 (comment)

[madb1lly]

Hi @jonalmeida,
Really? That looks more like hold and swipe than tap and hold... another reason to get clarification from @brampitoyo 😆
Cheers

[M86xKC]

This gesture is currently considered to be used to open tab tray, see #11862

We can still use swipe up and hold, no?

[brampitoyo]

@madb1lly @M86xKC Unfortunately, we can’t use swipe-and-hold.

We do have the ability to use hold-and-swipe – which a reverse of swipe-and-hold. It’s when you tap on the side of the screen and hold it for a moment. The system lets you know that something is happening, by opening a little bit of a sheet. If you then swipe to the centre of the screen, the screen expands.

This gesture, while smart, has zero affordance. There’s no indicator which tells you “this is where you can tap-hold-and-swipe”, because putting a visual like that would distract people away from the website (main content) they’re viewing. If you don’t know exactly how to trigger it, it’s not discoverable.

Plus, Android designed this gesture specifically to access the three-line menu, and not for any other element.

For those reasons, we decided against adopting this gesture in favour of simply inserting an unmistakeable ← icon inside the main menu.

[chriscjs]

This works on my Pixel 3a running stock but not on Nexus 6p running Lineage OS 17.1. Both phones have same version of Firefox beta (8-18). So it obviously is possible.
Edit:
Just tried it on my Galaxy S4 running Lineage OS 17.1 and it works! So just my 6p where it does not.

[person808]

This works on my Pixel 3a running stock but not on Nexus 6p running Lineage OS 17.1. Both phones have same version of Firefox beta (8-18). So it obviously is possible.

@chriscjs What is "this" referring to? Implementations of gesture navigation vary between manufacturer and Android versions so relying on a swipe and hold gesture is not an option here. FWIW, swipe and hold does not work on my Pixel 2 XL also on stock Android. If a swipe and hold does work its simply a nice thing that the manufacturer/ROM developer has implemented, but not something that can be relied upon working..

[chriscjs]

Long pressing back button at bottom of screen shows tab history, which is what I thought this issue was about. Also works in Chrome on Nexus 6p. All three phones with Android 10 (LiOS 17.1 is Android 10).

[person808]

Ah ok. The long press back button is already implemented which is why this was closed :) If it doesn't work then its probably a device/manufacturer specific issue and you should open a new issue to track it.