Onboarding and the forgotten-PIN screen still have no way back #67

New Issue

Closed

opened 2026-08-20 21:22:38 -05:00 by null · 0 comments

null commented

2026-08-20 21:22:38 -05:00

Owner

Filed rather than folded into the back-arrow work, because both sit outside the settings navigation graph and have different rules.

What is true now. app/src/main/kotlin/dev/privacyllc/period/feature/onboarding/OnboardingScreen.kt:118 has an in-flow 'Back' control, but the system gesture exits onboarding entirely rather than stepping back through it. ForgotPinScreen is rendered by LockScreen (app/.../feature/lock/LockScreen.kt:83-86) on an erasing flag, not as a navigation destination, so system back does not return to the PIN entry either — only the on-screen Cancel does.

What it costs. Small, but it is the same promise as everywhere else: the arrow and the gesture should do the same thing, and a screen with internal steps should step back through them. The forgotten-PIN screen is the one place where an accidental exit is least welcome.

What to do. Apply the same mode-aware BackHandler pattern the settings pages get: enabled only inside a step, returning to the previous step, falling through to whatever hosts the screen at the first step. Onboarding is a RootState branch rather than a destination (navigation/PeriodApp.kt:74-88), so decide deliberately what back means at its first step — exiting the app is a defensible answer, silently skipping onboarding is not.

Traps. The lock screen and the erase screen are inside AppLockGate, which disposes the whole app subtree on relock; a BackHandler there dies with the composition, which is correct but must not be relied on for state that should survive. Do not let back on the erase confirmation leave a half-typed 'ERASE' visible.

Verify: back from the erase confirmation returns to PIN entry rather than leaving the lock screen; back within onboarding steps returns to the previous step, asserted by a compose test in the style of LockSettingsBackTest.

Filed rather than folded into the back-arrow work, because both sit outside the settings navigation graph and have different rules. **What is true now.** `app/src/main/kotlin/dev/privacyllc/period/feature/onboarding/OnboardingScreen.kt:118` has an in-flow 'Back' control, but the system gesture exits onboarding entirely rather than stepping back through it. `ForgotPinScreen` is rendered by `LockScreen` (`app/.../feature/lock/LockScreen.kt:83-86`) on an `erasing` flag, not as a navigation destination, so system back does not return to the PIN entry either — only the on-screen Cancel does. **What it costs.** Small, but it is the same promise as everywhere else: the arrow and the gesture should do the same thing, and a screen with internal steps should step back through them. The forgotten-PIN screen is the one place where an accidental exit is least welcome. **What to do.** Apply the same mode-aware `BackHandler` pattern the settings pages get: enabled only inside a step, returning to the previous step, falling through to whatever hosts the screen at the first step. Onboarding is a `RootState` branch rather than a destination (`navigation/PeriodApp.kt:74-88`), so decide deliberately what back means at its first step — exiting the app is a defensible answer, silently skipping onboarding is not. **Traps.** The lock screen and the erase screen are inside `AppLockGate`, which disposes the whole app subtree on relock; a `BackHandler` there dies with the composition, which is correct but must not be relied on for state that should survive. Do not let back on the erase confirmation leave a half-typed 'ERASE' visible. Verify: back from the erase confirmation returns to PIN entry rather than leaving the lock screen; back within onboarding steps returns to the previous step, asserted by a compose test in the style of `LockSettingsBackTest`.