yonlu/yellowjacket
1
1
Fork 0
Code Issues 55 Pull Requests 6 Actions Packages Projects Releases 12 Wiki Activity

The launch records two history entries, so the first back press does nothing (and does not exit on Android) #142

New Issue
Closed
opened 2026-08-19 21:45:06 +00:00 by logan · 0 comments
logan commented 2026-08-19 21:45:06 +00:00
Collaborator
Copy Link
Copy Source

Report

The app records two history entries before the user has touched
anything, so the first back press at the root does nothing visible —
and on Android it is swallowed rather than exiting the app.

Measured on make dev-headless SEED=default, at launch, with no
interaction:

history.state  ->  { yjNav: { view: 'home' }, yjIdx: 1 }
history.back()
history.state  ->  { yjNav: { view: 'home' }, yjIdx: 0 }   // same view

Why

frontend/index.ts navigates twice on startup, and both are
deliberate in isolation:

  1. the unconditional navigate → home at the foot of the file (H-8,
    "Land on Home"), which paints without waiting for the backend; and
  2. GetDefaultPage().then(...), which navigates to the configured
    launch page when the call returns.

The first replaces the launch entry, which is the rule that keeps one
back press exiting the app. The second is an ordinary navigation and
therefore pushes — even when it resolves to the same page, which is
the default. So the stack is [home, home] and the app is one entry
deep before anybody has done anything.

Consequences

  • On Android, MainActivity.onBackPressed asks webView.canGoBack(),
    which is now true at the root: the first press replays home over home
    and only the second exits. The "back does not quit from the root"
    rule is defeated by there being two launch navigations rather than
    one.
  • On desktop it was invisible until #6 gave the chrome a Back button
    with a disabled state: it renders enabled at launch and does
    nothing when pressed, which is how this was found.
  • Where the configured launch page is not Home, the phantom entry is
    Home — so back from a fresh launch lands somewhere the user never
    chose.

Direction

The configured-page navigation is part of launching, not a
navigation away from something, so it should replace the launch entry
rather than push. recordNavigation takes a _replace detail flag,
honoured only while the session is still at index 0 — if the user has
already navigated (the call is asynchronous and they can), it pushes as
any other navigation would, or a slow backend call would clobber an
entry they made.

Fixed as part of #6, since the Back button's disabled state cannot be
correct without it. Filed separately because it is a distinct defect
with its own reproduction, and it predates that work by five phases.

**Report** The app records **two** history entries before the user has touched anything, so the first back press at the root does nothing visible — and on Android it is swallowed rather than exiting the app. Measured on `make dev-headless SEED=default`, at launch, with no interaction: ``` history.state -> { yjNav: { view: 'home' }, yjIdx: 1 } history.back() history.state -> { yjNav: { view: 'home' }, yjIdx: 0 } // same view ``` **Why** `frontend/index.ts` navigates twice on startup, and both are deliberate in isolation: 1. the unconditional `navigate → home` at the foot of the file (H-8, "Land on Home"), which paints without waiting for the backend; and 2. `GetDefaultPage().then(...)`, which navigates to the *configured* launch page when the call returns. The first *replaces* the launch entry, which is the rule that keeps one back press exiting the app. The second is an ordinary navigation and therefore **pushes** — even when it resolves to the same page, which is the default. So the stack is `[home, home]` and the app is one entry deep before anybody has done anything. **Consequences** - On Android, `MainActivity.onBackPressed` asks `webView.canGoBack()`, which is now true at the root: the first press replays home over home and only the second exits. The "back does not quit from the root" rule is defeated by there being two launch navigations rather than one. - On desktop it was invisible until #6 gave the chrome a Back button with a disabled state: it renders *enabled* at launch and does nothing when pressed, which is how this was found. - Where the configured launch page is not Home, the phantom entry is Home — so back from a fresh launch lands somewhere the user never chose. **Direction** The configured-page navigation is part of *launching*, not a navigation away from something, so it should replace the launch entry rather than push. `recordNavigation` takes a `_replace` detail flag, honoured only while the session is still at index 0 — if the user has already navigated (the call is asynchronous and they can), it pushes as any other navigation would, or a slow backend call would clobber an entry they made. Fixed as part of #6, since the Back button's disabled state cannot be correct without it. Filed separately because it is a distinct defect with its own reproduction, and it predates that work by five phases.
logan closed this issue 2026-08-19 22:27:39 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Area/Design
Area/Downloads
Area/Explore
Area/Library-UI
Area/Metadata
Area/Packaging
Area/Player
Area/Queue
Area/Settings
Area/Shell-Nav
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
 Platform/Android
Platform/Desktop
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Medium
3
The priority is medium
Priority
Low
4
The priority is low
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
In Progress
Somebody is actively working on this right now
No labels Area/Shell-Nav Kind/Bug Platform/Android Platform/Desktop
Priority
Medium
3
Reviewed
Confirmed
1
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
logan yonlu
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yonlu/yellowjacket#142