Global back and forward, and the launch entry that made Back a lie #144

Merged

logan merged 4 commits from feat/6-global-back-forward into main 2026-08-19 22:27:39 +00:00

Conversation 0 Commits 4 Files Changed 16

+686 -21

4 Commits

Author	SHA1	Message	Date
logan	ea16e07c46	docs: record the back/forward chrome and the two launch navigations ... Both belong beside the rules that already keep the history stack honest: the depth counting, because forward is the case one counter cannot express, and the second launch navigation, because it is what silently defeated the first rule on the list.	2026-08-19 18:09:10 -04:00
logan	4f47c85208	test(e2e): cover global back/forward, including the launch entry ... Five journeys the control has to get right: nothing offered at the root in either direction, walking both ways with the availability changing as it goes, reaching the detail view a tab click left behind (which is the report), the forward list being dropped when the user navigates from the middle, and the control standing down below 900px. The first fails on the build before the launch entry was fixed -- enabled, and doing nothing when pressed. It is the assertion that pins that defect, which otherwise has no visible symptom on desktop at all.	2026-08-19 18:09:10 -04:00
logan	603728a3fb	fix(shell): let the landing page replace the launch entry ... The app navigates twice on startup and both are deliberate: the eager `navigate -> home` that paints without waiting for the backend, and the configured page `GetDefaultPage()` resolves to a moment later. Only the first replaced the launch entry, so the second stacked on it and a fresh session was already one entry deep before the user had touched anything. The first back press therefore replayed home over home. On desktop that was invisible until this branch drew a Back button, which rendered live at the root and did nothing; on Android `webView.canGoBack()` was true, so the press that should have exited the app was swallowed -- the exact fault the replace-the-launch-entry rule exists to prevent, defeated by there being two launch navigations rather than one. Guarded on still being at index 0 rather than on a flag: that call is asynchronous and the user can navigate while it is in flight, so past the root this is an ordinary navigation and a slow answer cannot overwrite an entry they made. Closes #142	2026-08-19 18:09:10 -04:00
logan	018d857746	feat(shell): global back and forward in the top bar ... The history stack has been global since the Android back gesture landed -- every navigation is an entry and `popstate` restores any of them in either direction. What the report describes as "back is tab-scoped" is that the only way back was a detail view's own button, which leaves the screen with the view it belongs to: click over to Tracks and the album you were reading is still one entry away with nothing on screen saying so. `<nav-history>` is that affordance, plus `nav.back` / `nav.forward` on Alt+Left / Alt+Right -- the browser's own combination, and clear of the bare arrows that seek, since a binding matches on its full canonical string. Forward is not back negated, which is why the old `pushedEntries` counter is gone rather than extended: `popstate` carries no direction and fires identically both ways, so one counter decremented on every pop reads a forward as a second back. Each entry carries its index and the shell keeps the current one and a high-water mark, which also survives a jump of more than one. The buttons dispatch the events the rest of the app already dispatches rather than calling `history` themselves -- the shell owns the guard that stops a press at the root leaving the app, and a second caller reaching for history is how the old `navStack` came to disagree with the platform. Below 900px the control stands down: the top bar is what runs out of room first below that, and nothing becomes unreachable -- the shortcuts are global at every width and the phone has the platform's gesture. Closes #6	2026-08-19 18:08:55 -04:00