enhancement: back navigation to take back to the previous page

[criticalAY]

Purpose / Description

• fix: Navigate Up versus Close #17623 fixed the issue where the close button was navigating the user back, and after this the nav icon was used but the nav icon was taking the user back to deck selection screen
• There was a search option in menu which is not required IMO as there is already an option to search decks in webview and the search option in menu is redundant so this PR removes that and introduces a close webview button clicking which would close the webview
• Also the navigation icon now works as expected i.e. taking the user to previous screen and closing the screen if there is none to navigate back.

Fixes

• Fixes Back button in download deck leave the webview #19362

Approach

Remove search option as it is redundant and introduces a close icon instead

How Has This Been Tested?

Google Pixel API 35 Emulator
Screen_recording_20251029_144107.webm

Learning (optional, can help others)

NA

Checklist

Please, go through these checks before submitting the PR.

• You have a descriptive commit message with a short title (first line, max 50 chars).
• You have commented your code, particularly in hard-to-understand areas
• You have performed a self-review of your own code
• UI changes: include screenshots of all affected screens (in particular showing any new or changed strings)
• UI Changes: You have tested your change using the Google Accessibility Scanner

[github-actions]

Important

Maintainers: This PR contains Strings changes

1. Sync Translations before merging this PR and wait for the action to complete
2. Review and merge the auto-generated PR in order to sync all user-submitted translations
3. Sync Translations again and merge the PR so the huge automated string changes caused by merging this PR are by themselves and easy to review

[BrayanDSO]

Please split the Search removal part into another commit.

Also, discussing it will be a blocker for the PR, so I suggest splitting it into another PR.

[lukstbit]

No, I don't think this is ok.

We always have two options to "exit" a screen, BACK and toolbar Up button which are established patterns. Adding an "X" just clutters the UI.

[criticalAY]

It is cluttered right now but after the search button is removed it will be fine IMO, I am ok fixing the bug but the problem with that case would be that if user navigates too much in the webview i.e. clicking multiple urls then they would have to press back button a lot of times to go to deck selection screen itself hence I think having a close button is better just in case so that we cover worst case but if others are not happy then I would remove it and simply fix the nav bug

[lukstbit]

clicking multiple urls then they would have to press back button a lot of times to go to deck selection screen itself

They have the navigation UP button for that, which is specifically for this case(always go back to the previous screen). By cluttering the screen I mean we would be adding a button in the toolbar to go to the previous screen when we already have a button in the toolbar to go to the previous screen.

I think having a close button is better

This is not normal behavior for apps that implement the normal toolbar.

[criticalAY]

I can go with the navigation issue fix which the original issue states I am totally fine with that, waiting for others to respond

[BrayanDSO]

Agreed with lukstbit. Back button goes back, toolbar button closes the screen. No new buttons.

[criticalAY]

If we want to fix the issue OP raise then this would make the behaviour of back button and the navigation button in toolbar same but if we want them to act differenly then I think this PR and the issue can be closed, but its gonna be confusing and I think thats why @Arthur-Milchior raised that issue, leaving to reviewers

[mikehardy]

I dunno. I loaded this up on an emulator as is right now and I think it behaves the way I'd expect, without thinking too deeply on the original issue (as in, I read the issue, I read all the comments here, but then I cleared my mind and just used the app). It works the way I expect an app to work

inside the webview:

• the back arrow goes back into preview webview state unless I'm out of webview state then pops me back on app back stack
• the system back does...the exact same (which I expect)
• the webview home icon takes me to the root of the webview which...makes sense, I'm not bothered or surprised really - it didn't go too far back, which is the only possible surprise for an icon that has an action you're not sure about as a user, so this passes for me

UI is uncluttered. I think it does solve the OP issue. I like it as is right now.

[BrayanDSO]

I strongly believe that both this PR and the original issue should be closed.

The Navigate up button of the toolbar is supposed to leave the screen. If you want to go back in the WebView navigation, press the device back button. That's it.

Changing it breaks both internal consistency among the app and the external consistency with the whole Android ecosystem.

[lukstbit]

App bar UP button is always expected to go the previous screen. Changing it to make it navigate through the WebView's history is a clear no from me.

[mikehardy]

Interesting, to me, since the integration of the web screens are made to be as seamless as they are, they feel as a user like regular screens. I'm not mentally differentiating "this is a web page" from "this is an app screen". Thus my take that it "felt" right with this PR as is.

Maybe my perspective is off or my understanding is off though. @BrayanDSO and @lukstbit - is your mental model of the app strictly differentiating between "native android screen" and "pages within some webview" such that screens and pages are different and unequal ? And your dislike for this is based on that?

[BrayanDSO]

When I see this exact icon in an Android toolbar, in any screen and in any app, it means leaving the page.

[mikehardy]

Right - so, if I've clicked into "download shared decks" (a page?), and then tapped "Japanese" (for language decks) I am now on a new webview page, but it feels like a "page", and then if I tap a specific deck I'm on that deck page.

If I tap that arrow, in this PR when I built it and looked, I go from the specific deck back to the list of Japanese decks, then to the main shared decks page, and then back out to the deck list (where I was when I tapped the FAB for shared decks)

So, it felt to me like it was backing out in a sane way? But hey, I could be wrong 🤷 (like maybe I'm too "web"y of a mental model and the android toolbar emphasis you made is the differentiator, and I just don't think that way

[lukstbit]

I don't think the discussion is about what a screen is it's more about what we expect to happen when using either of the buttons:

• app bar UP button: get me out of the screen now. From the official tutorial for the app bar:

  Users need an easy way to get back to your app's main screen. To do this, provide an Up button on the app bar for all activities except the main one. When the user selects the Up button, the app navigates to the parent activity.

• BACK button: the navigation docs says that they are the same when inside your own task(if we don't navigate to any WebView page UP and BACK produce the same effect, exit the screen), but if we do have a history of WebView navigation IMO BACK should revert through the history and UP should continue to exit the screen. It would feel kind of silly to have two options(three if we count predictive BACK gesture which is a BACK action) doing the same thing but nothing to exit the screen directly.

In a web browser the analogy would be UP being the close tab button(not matter how much history I have in this tab I'm done with it and I want to go to tab next to it) and BACK being the browser's go back a page(most browser don't close the tab when you get to the first page, in android BACK does this).

[criticalAY]

I am ok with anything it being closed or merged, and since most of you are in favour of closing it so lets do it

[mikehardy]

but if we do have a history of WebView navigation IMO BACK should revert through the history

Okay, but the app without this PR, if you choose the back icon while deep in a web stack, closes the whole web stack and punts you out of the webview. I just tested it. This is unexpected for me.

So, I prefer the behavior of this PR.