clawbot
5442b3ce67
All checks were successful
check / check (push) Successful in 48s
restoreView() refuses to reopen the popup ONTO a non-restorable view, but the stack behind it was restored verbatim, so a screen the popup will not render -- export-privkey, show-phrase -- could sit in it. Back then landed on a view the popup had declined to restore, and show-phrase has no Back control to leave by. No secret is exposed: those screens are empty precisely because nothing is restored into them. This is navigation, not disclosure. loadState() now truncates the stored stack at the first entry outside RESTORABLE_VIEWS rather than splicing that entry out, so the result stays a prefix of what was stored and every surviving entry keeps exactly the Back target it had; splicing would silently re-point the entry above the hole at a different screen. A stack truncated to nothing under a restorable non-root view gets main beneath it, so Back always has somewhere to go. Stacks with no unrenderable entry are restored unchanged. A stored stack that is not an array runs through the same rule instead of returning early, so a corrupt stack does not fall back on the goBack() behaviour the explicit main exists in order not to depend on. The filter is on load, not on save: the live in-session stack is legitimate, since the screen really is rendered while the popup is open, and only a load-side filter also repairs the stacks already in storage, including ones written before a view left the set. Out of scope, tracked separately: a restorable view sitting in the stack is unhidden by goBack() without being re-rendered, so it can still come up blank on a freshly reopened popup. That is a general navigation defect, independent of this filter, and is #268.
11 KiB
11 KiB