fix(client): back navigation follows history, not always the landing screen #374

Merged

james merged 1 commit from fix-drawer-back-history into main 2026-06-29 15:17:41 +00:00

Conversation 1 Commits 1 Files changed 1 +6

james commented 2026-06-29 15:11:04 +00:00

Owner

Copy link

Bug: back always returned to Chat regardless of where you came from.

Root cause: the (app) Drawer left backBehavior at its default. The vendored drawer/tab router defaults to backBehavior: "firstRoute" (confirmed in BaseTabRouter({ …, backBehavior = 'firstRoute' })), which sends every back action — Android hardware back, browser back, and the in-app back buttons via router.back() — to the first/landing route, ignoring history. After the default landing moved to Chat (#373), that surfaced as "back always goes to Chat."

Fix: set the Drawer's backBehavior="history" so back pops to the actual previous screen. One line in app/(app)/_layout.tsx.

This makes the network detail screens' existing goBackOr(router, "/network") behave correctly — router.back() now returns to the prior screen when there's history, and still falls back to the logical parent (/network) on a cold start / deep link (so you also get "up categorically" for free in the no-history case).

Verification (local)

• typecheck ✓ (confirms backBehavior is a valid <Drawer> prop) · lint ✓ · test ✓ 172 · semgrep ✓ 0 findings

⚠️ Needs maintainer verification

Navigation behavior isn't covered by the node-env tests — please confirm on device/web: from a person/org detail → back returns to Network (not Chat); from Network → back returns to the previous tab; and a cold-start/deep-link straight onto a detail screen still lands "up" on Network.

Direct bug report (no ticket).

🤖 Generated with Claude Code

**Bug:** back always returned to Chat regardless of where you came from. **Root cause:** the `(app)` Drawer left `backBehavior` at its default. The vendored drawer/tab router defaults to `backBehavior: "firstRoute"` (confirmed in `BaseTabRouter({ …, backBehavior = 'firstRoute' })`), which sends **every** back action — Android hardware back, browser back, and the in-app back buttons via `router.back()` — to the first/landing route, ignoring history. After the default landing moved to Chat (#373), that surfaced as "back always goes to Chat." **Fix:** set the Drawer's `backBehavior="history"` so back pops to the actual previous screen. One line in `app/(app)/_layout.tsx`. This makes the network detail screens' existing `goBackOr(router, "/network")` behave correctly — `router.back()` now returns to the prior screen when there's history, and still falls back to the logical parent (`/network`) on a cold start / deep link (so you also get "up categorically" for free in the no-history case). ## Verification (local) - `typecheck` ✓ (confirms `backBehavior` is a valid `<Drawer>` prop) · `lint` ✓ · `test` ✓ 172 · semgrep ✓ 0 findings ## ⚠️ Needs maintainer verification Navigation behavior isn't covered by the `node`-env tests — please confirm on device/web: from a person/org detail → back returns to Network (not Chat); from Network → back returns to the previous tab; and a cold-start/deep-link straight onto a detail screen still lands "up" on Network. Direct bug report (no ticket). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

james added 1 commit 2026-06-29 15:11:04 +00:00

fix(client): back navigation follows history, not always the landing screen ... 39f734691d

The (app) Drawer left backBehavior at its default ("firstRoute"), so every
back action — system back, browser back, and the in-app back buttons via
router.back() — jumped to the first/landing route regardless of where you
came from. After the default landing moved to Chat (#373) that meant back
always went to Chat.

Set the Drawer's backBehavior to "history" so back pops to the actual
previous screen. The network detail screens' goBackOr(router, "/network")
now genuinely returns to the prior screen when there's history, and still
falls back to the logical parent on a cold start / deep link.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

forgejo-actions commented 2026-06-29 15:17:14 +00:00

Copy link

📊 Test coverage

Patch coverage: no testable lines changed.

Overall (app/, lib/, db/, excluding UI per ADR-0019):

Metric	Value	Soft target
Lines	79.4% ✅	≥ 50%
Branches	71.2% ⚠️	≥ 75%
Functions	80.5%	informational

Soft thresholds per ADR-0019. Coverage is informational and does not block merge.

<!-- coverage-comment --> ## 📊 Test coverage **Patch coverage:** no testable lines changed. **Overall** (`app/`, `lib/`, `db/`, excluding UI per ADR-0019): | Metric | Value | Soft target | |---|---|---| | Lines | 79.4% ✅ | ≥ 50% | | Branches | 71.2% ⚠️ | ≥ 75% | | Functions | 80.5% | informational | Soft thresholds per [ADR-0019](docs/adr/0019-coverage-soft-targets.md). Coverage is informational and does not block merge.

james merged commit 903571804c into main 2026-06-29 15:17:41 +00:00

james deleted branch fix-drawer-back-history 2026-06-29 15:17:41 +00:00

james referenced this pull request from a commit 2026-06-29 15:17:42 +00:00

Merge pull request 'fix(client): back navigation follows history, not always the landing screen' (#374) from fix-drawer-back-history into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

area:auth

Authentication and authorization

  

area:ci

Forgejo Actions, build, test, security, release

  

area:db

Database abstraction, migrations, persistence

  

area:infra

Containerization, deployment, foundational tooling

  

area:native

React Native app (Android + Linux Flatpak)

  

area:pwa

PWA / web frontend

  

area:service

Backend service, API routes, persistence

  

epic

High-level tracker; links several feature tickets

  

feature

A user-facing feature

  

foundation

Foundational work that other tickets build on

No labels

area:auth

area:ci

area:db

area:infra

area:native

area:pwa

area:service

epic

feature

foundation

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

james/carol!374

No description provided.