diff options
| author | Adam Soltys <[email protected]> | 2026-09-10 22:08:26 -0700 |
|---|---|---|
| committer | Adam Soltys <[email protected]> | 2026-09-10 22:08:26 -0700 |
| commit | f0a5e0de3e68eee184b25ced2393329aec169f6d (patch) | |
| tree | b0d0450d93715a728f56f8fea3f6e533fc61f5d0 /src/features/sync.js | |
| parent | db5218ec83c1d84da5a2062e514b65132bcfe240 (diff) | |
| download | coinosv3-f0a5e0de3e68eee184b25ced2393329aec169f6d.tar.gz coinosv3-f0a5e0de3e68eee184b25ced2393329aec169f6d.zip | |
The padlock answers where you tap it, including on your profile page.
Feature screens (a profile, a chat thread, a search) are drawn ahead of the
wallet screen — and the padlock's "Protect this device?" card was drawn BY
the wallet screen. So tapping the padlock from a profile did nothing you
could see: the card was waiting behind the page, and only appeared once you
navigated back to the wallet. The ask now outranks feature screens (with
onboarding still ahead of it), and declining leaves you exactly where you
tapped, because nothing else moves.
A lock that goes through does move: it drops the profile/chat/search the
padlock was tapped from, so you land on the wallet wearing a closed padlock
instead of reading a profile page with only a toast to say what happened.
Logging out drops it too — a page belonging to the locked session had no
business outliving it, or greeting whoever unlocks next.
tools/padlock-ask-test.js covers the tap and the decline.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_019mrt228Upn9nNCwGixzSLx
Diffstat (limited to 'src/features/sync.js')
0 files changed, 0 insertions, 0 deletions
