Fenix: [Bug] inconsistent back button behaviour in library

Created on 2 Aug 2019  ·  13Comments  ·  Source: mozilla-mobile/fenix

Steps to reproduce

1a) open your bookmarks
1b) open a bookmark
1c) press the back button

2a) open your history
2b) open a page from your history
2c) press the back button

Expected behavior

Either return to the library view or to the start screen, but do the same in both cases.

I clearly prefer the behaviour of the history (return to the library view).

Actual behavior

after 1c) Fenix opens the start screen
after 2c) Fenix returns to the history

Device information

  • Android device: HTC U11 / Android 8.0
  • Fenix version: master branch revision 46b2d6f937f267137f7744256d829eb5d5d40550
P2 ready 🐞 bug

Most helpful comment

Let's maintain the stack and get people back to history or bookmarks when tapping on back button.

All 13 comments

@cadeyrn Good catch!

Hi @boek , Can you please tell us how it should work?
1) Both return to the library.
2) Both return to the home screen.

I saw in the nav_graph.xml that currently this is the expected behaviour for bookmark fragment (to go back to the home screen in this case).

<action
      android:id="@+id/action_bookmarkFragment_to_browserFragment"
      app:destination="@id/browserFragment"
      app:popUpTo="@id/libraryFragment"
      app:popUpToInclusive="true" />

The current behaviour is terrible, not only does the Android back button not return the user to the Bookmark tree view or History view which the user had (painstakingly for bookmark power users with folder structures) navigated to before opening an entry (at least make it an option!), but currently it also closes the browser and returns the user to the Android homescreen.

1.3.1 build 12341950

The Android homescreen navigation issue mentioned by @eggsgent is fixed in Nightly, but we should still standardize the library behavior

AFAIK no UX decision has been made about this behavior, so I'm going to ask them for feedback here.
UX - When going to browser from home via a library page: do we want pressing back from browser to always get you to home (current behavior from bookmarks), or do you want to maintain the stack and keep bookmarks/history so you can press back from browser to get back to them (current behavior from history)?

@topotropic is out at a conference but can respond tomorrow when she returns. thanks!

Let's maintain the stack and get people back to history or bookmarks when tapping on back button.

@ekager
STR:

  1. Open a webpage.
  2. In that tab go to library>history/bookmarks again and open a new link.
  3. Tap back.
    Result: It will go to homescreen, not to history/bookmarks.

Works fine if you go to library from the homescreen, but not from a tab.

So chatted with @mcarare about this ticket and the slightly strange behavior detailed above but posting here for posterity. :)

We use an extension function alreadyOnDestination because if you have 2 BrowserFragments that are created at any time, we get some nasty GeckoView crashes ("display already acquired").

alreadyOnDestination just checks if we're already on BrowserFragment and if not, it tries to pop to it. Unfortunately, this means if you go to Settings/Library from BrowserFragment and then open something in browser, it'll run through this alreadyOnDestination, pop to the last BrowserFragment and clear the stack of anything that happened after the last time you were on BrowserFragment.

I'm not sure if there is a way to both pop to an existing BrowserFragment and also maintain the library stack here. In addition, even if we did maintain the stack what if you kept going to open Library items from the Browser. Should we maintain a stack like Browser -> Library -> Bookmarks -> Browser -> Library -> Bookmarks ? It seems like that wouldn't be great behavior either when the user would back press it could be quite confusing.

I think we should punt on this ticket for now but maybe discuss our ideal interactions around browser and navigation with UX at some point.

@ekager Thanks for posting these details. Keeping Library fragment makes Fenix act more like an app, versus the browser (like Chrome) behaviour to navigate back from a tab to the history of that tab or homepage (if there is no history)
I agree that we should further discuss these interactions.

@topotropic do you have any immediate feedback on https://github.com/mozilla-mobile/fenix/issues/4517#issuecomment-533608455? Maintaining the stack from Browser could get tricky. Or would you rather we file a followup about this?

Huh. As @sv-ohorvath mentioned:

  • Stack works if you go to library from the homescreen
  • Stack breaks if you go to library from a tab

At least we’ve fixed the homescreen problem for now. Yay! For the tab scenario, let’s file a follow-up issue.

Was this page helpful?
0 / 5 - 0 ratings