Fix BrowserScreen back button: step through page history before closing

Reasoned through the code rather than reproducing live (per explicit
instruction). An earlier change made back always close the whole browser
screen in one press, regardless of how many pages deep the session was --
on the theory that stepping back one page at a time through a long
search/login session was tedious. That trade was wrong: it meant a single
accidental back press (system gesture or the in-app arrow) could silently
destroy an entire multi-page browsing session with no way to recover it,
and it doesn't match how every other browser or in-app browser view on
the platform behaves.

Now: go back through the WebView's own page history first
(canGoBack()/goBack()), and only close the screen once there's nowhere
left to go back to. Both the system back gesture and the in-app top-bar
arrow route through the same handleBack(), so they behave identically.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EZ7ikw2ukGJFTHE3bJS7zL

1 files changed, 20 insertions, 9 deletions

diff --git a/app/src/main/java/org/terst/feedreader/ui/BrowserScreen.kt b/app/src/main/java/org/terst/feedreader/ui/BrowserScreen.kt
index 6eb5b71..de9416b 100644
--- a/app/src/main/java/org/terst/feedreader/ui/BrowserScreen.kt
+++ b/app/src/main/java/org/terst/feedreader/ui/BrowserScreen.kt
@@ -50,21 +50,32 @@ fun BrowserScreen(startUrl: String, onBack: () -> Unit) {
     var title by remember(startUrl) { mutableStateOf<String?>(null) }
     var webViewRef by remember(startUrl) { mutableStateOf<WebView?>(null) }
 
-    // Deliberately NOT "goBack() if the WebView has history, else exit" -- that means
-    // however many pages deep a search/login session went (search results -> article ->
-    // another link -> ...), leaving requires tapping back that many times first. Reported
-    // live as not making sense for this kind of multi-page browsing. Back always just
-    // closes the screen now, both the system gesture and the in-app arrow; there's no
-    // separate in-page-back affordance, matching how every other screen in this app behaves.
-    BackHandler(onBack = onBack)
+    // Real browser-style back: step back through THIS WebView's own page history first
+    // (search results -> article -> another link -> ...) and only close the screen once
+    // there's nowhere left to go back to. An earlier version made back always close the
+    // screen outright, on the theory that stepping through a deep session one page at a
+    // time was tedious -- but that meant a single back press (system gesture or the in-app
+    // arrow) could silently throw away an entire multi-page browsing/login session, which
+    // is worse: there's no way to recover it, and it doesn't match how every other browser
+    // (or in-app browser view) on the platform behaves. Both the system back gesture and
+    // the in-app arrow go through the same path below, so they behave identically.
+    fun handleBack() {
+        val webView = webViewRef
+        if (webView != null && webView.canGoBack()) {
+            webView.goBack()
+        } else {
+            onBack()
+        }
+    }
+    BackHandler(onBack = ::handleBack)
 
     Scaffold(
         topBar = {
             TopAppBar(
                 title = { Text(title ?: "Browser", maxLines = 1, overflow = TextOverflow.Ellipsis) },
                 navigationIcon = {
-                    IconButton(onClick = onBack) {
-                        Icon(Icons.Default.ArrowBack, contentDescription = "Close browser")
+                    IconButton(onClick = ::handleBack) {
+                        Icon(Icons.Default.ArrowBack, contentDescription = "Back")
                     }
                 },
                 actions = {