A user who forgot their password but held their recovery phrase was permanently locked out: deletion was password-gated and re-importing the phrase was refused as a duplicate. Their only escape was destroying extension storage through browser internals, taking every other wallet with it. DeleteWallet gains an "I have lost my password" route that destroys the stored secret after the wallet's name is typed back. No password gate was added: requiring one to discard a secret protects nothing, since an attacker who wants destruction can uninstall the extension, and the only person it stops is the legitimate user who lost it. The screen is excluded from RESTORABLE_VIEWS and registers an onViewLeave cleanup. Deletion was chosen over re-import because a key wallet is duplicate-checked by address rather than xpub, so an xpub-only relaxation would leave that user still wedged; because re-import makes the user retype their recovery phrase into a live popup merely to change a password; and because it reaches no end state that delete-then-import plus scanForAddresses() does not. The attacker argument did not decide it — re-import clears the "no worse than the phrase alone" bar. All three AddWallet password hints now state the password cannot be recovered or reset and name that mode's only backup, the xprv mode correctly claiming no recovery phrase. deleteAddress.js no longer tells the user that deleting a wallet asks for a password, which this change made false. The typed confirmation collapses internal whitespace on both sides: a wallet renamed with two spaces displays with one, so the string a user could see and type could never match, making the confirmation untypable on the one screen whose purpose is un-wedging a stuck user. Measured, not reasoned, after review found the first reserve twice too large and pushing the Import button below the fold: #btn-add-wallet-confirm bottom 628.13 -> 580.13 at 360x600, scrollHeight 636 -> 600, hint box 48px identical across all three tabs and on re-entry. make check 40 suites / 828 tests, test-e2e 55/55, test-e2e-firefox 8/8.
36 lines
1.3 KiB
JavaScript
36 lines
1.3 KiB
JavaScript
// Views the popup may reopen onto.
|
|
//
|
|
// The popup persists the current view so that reopening the toolbar popup
|
|
// lands the user back where they were. Only views that can be fully
|
|
// re-rendered from persisted state belong here; every other view falls back
|
|
// to the nearest restorable parent (src/popup/index.js restoreView()).
|
|
//
|
|
// A view that displays a secret must NEVER be listed. Restoring onto one
|
|
// would put a private key or a recovery phrase on screen with no password
|
|
// prompt in front of it, on a popup the user may have reopened by accident.
|
|
// That is why "export-privkey" and "show-phrase" are absent.
|
|
//
|
|
// Nor may a view whose button destroys a wallet be listed, for the mirror
|
|
// reason: a popup reopened by accident must not land on the screen that
|
|
// erases key material. That is why "delete-wallet-confirm" and
|
|
// "delete-wallet-lost-password" are absent.
|
|
//
|
|
// Kept in its own module, with no dependencies, so tests can assert the
|
|
// exclusion directly rather than trusting a reading of the popup entry
|
|
// point, which cannot be required outside a browser.
|
|
const RESTORABLE_VIEWS = new Set([
|
|
"main",
|
|
"address",
|
|
"address-token",
|
|
"receive",
|
|
"settings",
|
|
"settings-addtoken",
|
|
"confirm-tx",
|
|
"transaction",
|
|
"wait-tx",
|
|
"success-tx",
|
|
"error-tx",
|
|
]);
|
|
|
|
module.exports = { RESTORABLE_VIEWS };
|