Fenix: Swipe left/right on site to go backward/forward in tab history

[person808]

Edit: Roadmap for what needs to be done

• Needs GeckoView work (likely would have the same issues as pull-to-refresh if implemented now)
  
  
  
  • [ ] If Android provides 2-button or 3-button navigation, only then should we implement our own custom swipe-to-navigate
  
  

Broken out from #176

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

There is no gesture to go back and forward in a tab's history. Going back requires pressing the back button and going forward requires opening the three dot menu.

One solution is to add a gesture to swipe left/right on a site to navigate backward/forward in tab history.

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

Currently, going back and forward in a tab's history requires moving your finger down to the toolbar or navigation bar. Android 10 gestures reduce the movement for going back, but not everyone has gesture navigation enabled.

IIRC, Safari on iOS has this gesture. Desktop browsers often allow a two-finger swipe on a touchpad to perform these actions.

Firefox on Mac:

Who will benefit from it?

People who use gestures to navigate, especially on larger devices.

[person808]

Some considerations:

1. Do we want to show a preview of the previous/next page for the gesture (I think safari does this)? Or do we want to show an indicator like the desktop screenshot above? Showing a preview is likely much more work and probably would require A-C work as well.
2. Should we allow swipe to go back to the home page? My gut instinct is no as there's no easy way to implement swipe to go forward from the home page.
3. In #1048, @brampitoyo proposed using a swipe and hold gesture to show the tab history backstack. If we want to do that we should make sure it plays well with this gesture. In my opinion, if we implement both gestures, showing an arrow indicator for this gesture make more sense than showing a preview of the previous/next page. Having a preview, then hiding it to show the tab history is a much more jarring animation than hiding an arrow.
   Chrome has an experimental setting (chrome://flags/#overscroll-history-navigation) that implements this behavior.
4. The spec for #3481 specifies switching gesture direction for RTL layouts. Is that something we want to do here as well?

[person808]

This is what chrome's gesture looks like after setting chrome://flags/#overscroll-history-navigation to "Enabled Navigation Sheet": https://streamable.com/uljnbl

Chrome's gesture only triggers when swiping from the edge of the screen so it doesn't work with Android 10 gestures. I wonder why they restrict it to the edge of the screen 🤔

[boek]

would we be able to get this to work with gesture based navigation?

[person808]

I think if we expose an API in EngineView to detect if a page can scroll horizontally then its possible. I _think_ GeckoView already provides the necessary info, it just needs to be exposed in A-C. My biggest concern is that we end up running into the same issues as pull-to-refresh since that uses similar APIs.

From the Fenix side, #12174 implements the code that would allow us to intercept swipes from anywhere. So it should be doable if everything goes right on the A-C side and I can get the touch events to propagate correctly.

[brampitoyo]

@person808 @boek One of my concerns about adding this gesture is the potential conflict with Android 10’s indiscriminate back gesture.

As far as I’m aware, Chrome elects not to do swipe-to-navigate if the system already does gesture navigation, providing only a forward button in the main menu.

My recommendation is the same: if Android provides gesture navigation, let’s not implement our own swipe. Except there are a few additions:

• When the forward button (inside the main menu) is long-pressed, show history stack
• When user swipes from the left/right edge (provided by Android) and hold, show history stack

On the other hand, if Android provides 2-button or 3-button navigation, only then should we implement our own custom swipe-to-navigate. The same additions are also present here:

• When the forward button (inside the main menu) is long-pressed, show history stack
• When the back button (provided by Android) is long-pressed, show history stack

Does this behaviour sound sensible to you?

If it is, then we can design a UI for it – I think Chrome’s is a good starting point, but we already have a pull-to-refresh, and can use the same circle size/background for this history navigation.

[Dunexus]

This behavior is really consistent between gesture and button navigation but also with desktop. 👍

Is it possible to use Android 10's gesture navigation and receive the "hold" event or do you have to handle it inside Fenix using custom UI and disable the back gesture provided by Android 10 ?

[person808]

@brampitoyo In general, that makes sense to me. I have some eng concerns with swipe-to-navigate and the history stack. I'll focus on the swipe-to-navigate gesture here and keep everything related to the history stack in #1048.

For swiping to go forward/back when system gestures are disabled, I think we should hold off on implementing this until pull-to-refresh is fixed. The fixes for pull-to-refresh from GeckoView will likely enable this gesture to be implemented. So this issue is blocked by GeckoView.

[carallo]

Some considerations:

1. Do we want to show a preview of the previous/next page for the gesture (I think safari does this)? Or do we want to show an indicator like the desktop screenshot above? Showing a preview is likely much more work and probably would require A-C work as well.

2. Should we allow swipe to go back to the home page? My gut instinct is no as there's no easy way to implement swipe to go forward from the home page.

3. In #1048, @brampitoyo proposed using a swipe and hold gesture to show the tab history backstack. If we want to do that we should make sure it plays well with this gesture. In my opinion, if we implement both gestures, showing an arrow indicator for this gesture make more sense than showing a preview of the previous/next page. Having a preview, then  hiding it to show the tab history is a much more jarring animation than hiding an arrow.
   Chrome has an experimental setting (chrome://flags/#overscroll-history-navigation) that implements this behavior.

4. The spec for #3481 specifies switching gesture direction for RTL layouts. Is that something we want to do here as well?

To me the "Safari style" with previews is the best implementation, with a pixel by pixel gesture. This would also allow to peak at the previus (or next) webpage in history in case of need, without actually going back and forward. It also gives a more natural and coutinous feeling for the browsing experience.
It's indeed true, as you said, that it would mean much more work and probably load for the phone, and the issue with the tab history. So if this considerations are true I would say it's also ok to go for the arrow style.

Either way I think it's very important for the gesture to be implemented. Not so many people are using Android 10, I would say it's a great minority, so very little people uses the Android built-in gestures and it would mean a great Plus Factor for Firefox in comparison to other browsers.

[brampitoyo]

Thanks @person808. This issue is now ready for Engineering to work on.

I know that we’d only be able to test how this feature “feels” after the code has landed. Let me know when this happens. We can then test it and make sure that it feels just right.

[person808]

Unassigning myself because I think that it is best to wait for the remaining pull-to-refresh issues to be fixed before we add another gesture that handles touch events over web pages. Unfortunately, its highly unlikely pull-to-refresh will be fixed before I have to return to school.

[carallo]

I've noticed pull down to refresh has been added on nightly. Is development progressing on this one?

Thank you!