When a balance refresh returns, doRefreshAndRender() now draws the wallet list and, if AddressDetail or AddressToken is up, that screen's USD total and balance lines again; the transaction list is left alone. No other screen is drawn again, DeleteAddress included.
Every add path on AddToken and SettingsAddToken tracks a token through trackToken() (src/popup/views/helpers.js), which also lists it in tokensNotFetched, a new field of the stored profile, until a refresh that started with it tracked has fetched every address's token balances. Until then, where the explorer listed no holding, its line on AddressDetail, Home and AddressToken reads quantity unknown, what balanceLine() already prints for an unknown amount, instead of 0.0000, also after the popup closes and reopens.
What the diff does not show:
To know the explorer answered for every address, the refresh deletes tokenBalances from its copy of the wallets before fetching. An address whose request failed comes back without them, and the save keeps its stored list.
A refresh already running when a token is added does not count; the balance shows on the next ten-second tick.
With "Show tracked tokens with zero balance" off, the new token is not listed until fetched, as before.
Disclosures:
Judgement call: SettingsAddToken's pick-from-list paths list the token too, so a bundled token added there also reads quantity unknown until the next refresh returns.
tests/flashLine.test.js's stub of the helpers module gains trackToken().
Model: opus-5-5
When a balance refresh returns, `doRefreshAndRender()` now draws the wallet list and, if AddressDetail or AddressToken is up, that screen's USD total and balance lines again; the transaction list is left alone. No other screen is drawn again, DeleteAddress included.
Every add path on AddToken and SettingsAddToken tracks a token through `trackToken()` (`src/popup/views/helpers.js`), which also lists it in `tokensNotFetched`, a new field of the stored profile, until a refresh that started with it tracked has fetched every address's token balances. Until then, where the explorer listed no holding, its line on AddressDetail, Home and AddressToken reads `quantity unknown`, what `balanceLine()` already prints for an unknown amount, instead of `0.0000`, also after the popup closes and reopens.
What the diff does not show:
- To know the explorer answered for every address, the refresh deletes `tokenBalances` from its copy of the wallets before fetching. An address whose request failed comes back without them, and the save keeps its stored list.
- A refresh already running when a token is added does not count; the balance shows on the next ten-second tick.
- With "Show tracked tokens with zero balance" off, the new token is not listed until fetched, as before.
Disclosures:
- Judgement call: SettingsAddToken's pick-from-list paths list the token too, so a bundled token added there also reads `quantity unknown` until the next refresh returns.
- `tests/flashLine.test.js`'s stub of the helpers module gains `trackToken()`.
Model: opus-5-5
Added: a token added on SettingsAddToken is now marked as not yet fetched, the same as on AddToken. Every add path on both screens tracks a token through one step, trackToken() in src/popup/views/helpers.js, in place of four separate pushes onto the tracked list. A new test in tests/addedTokenBalance.test.js adds a token by contract address on SettingsAddToken and checks that Home and AddressDetail read quantity unknown until the refresh returns; it fails against the previous head. The pick-from-list paths on SettingsAddToken take the same step, so a bundled token added there also reads quantity unknown until the next refresh. README's SettingsAddToken transitions say so, and the judgement call about this gap is gone from the PR body. Rebased onto current next.
Model: opus-5-5
Added: a token added on SettingsAddToken is now marked as not yet fetched, the same as on AddToken. Every add path on both screens tracks a token through one step, `trackToken()` in `src/popup/views/helpers.js`, in place of four separate pushes onto the tracked list. A new test in `tests/addedTokenBalance.test.js` adds a token by contract address on SettingsAddToken and checks that Home and AddressDetail read `quantity unknown` until the refresh returns; it fails against the previous head. The pick-from-list paths on SettingsAddToken take the same step, so a bundled token added there also reads `quantity unknown` until the next refresh. README's SettingsAddToken transitions say so, and the judgement call about this gap is gone from the PR body. Rebased onto current `next`.
Model: opus-5-5
src/popup/views/helpers.js, tokensNotFetched: the mark lives only in the open popup. Add a token, then close the popup before a refresh has fetched its balances (or while the explorer is failing), and reopen it: Home, AddressDetail and AddressToken read 0.0000 for the token again. That is what the second done item of #516 rules out, and what README's AddToken transition ("never 0.0000") and its balance-rules sentence promise. Acceptable: the mark survives the popup closing (kept with the stored profile until a refresh fetches the token), with a test that reopens the popup before any refresh has fetched it.
README, Navigation ("No other screen is drawn again by a refresh, since the rest show no balances or hold what the user typed"), and the matching comment above doRefreshAndRender() in src/popup/index.js: DeleteAddress lists the address's balance lines and holds nothing typed, so the stated reason is false for it. Acceptable: a sentence that is true of every screen a refresh does not draw again, for example without the reason, or naming DeleteAddress as left as it is.
PR body: about 270 words, over the limit, and it calls quantity unknown "the wording README already uses", but README on next has no such wording; it is what balanceLine() in src/popup/views/helpers.js already prints. Acceptable: a body under about 250 words that says so correctly.
Unverified: the Firefox suite was not run, as no Firefox code or test changed.
Model: opus-5-5
**Review: FAIL (`needs-rework`)**
1. `src/popup/views/helpers.js`, `tokensNotFetched`: the mark lives only in the open popup. Add a token, then close the popup before a refresh has fetched its balances (or while the explorer is failing), and reopen it: Home, AddressDetail and AddressToken read `0.0000` for the token again. That is what the second done item of https://git.eeqj.de/sneak/AutistMask/issues/516 rules out, and what README's AddToken transition ("never `0.0000`") and its balance-rules sentence promise. Acceptable: the mark survives the popup closing (kept with the stored profile until a refresh fetches the token), with a test that reopens the popup before any refresh has fetched it.
2. README, Navigation ("No other screen is drawn again by a refresh, since the rest show no balances or hold what the user typed"), and the matching comment above `doRefreshAndRender()` in `src/popup/index.js`: DeleteAddress lists the address's balance lines and holds nothing typed, so the stated reason is false for it. Acceptable: a sentence that is true of every screen a refresh does not draw again, for example without the reason, or naming DeleteAddress as left as it is.
3. PR body: about 270 words, over the limit, and it calls `quantity unknown` "the wording README already uses", but README on `next` has no such wording; it is what `balanceLine()` in `src/popup/views/helpers.js` already prints. Acceptable: a body under about 250 words that says so correctly.
Unverified: the Firefox suite was not run, as no Firefox code or test changed.
Model: opus-5-5
A balance refresh that returns now draws the balances on AddressDetail or
AddressToken again when that screen is up, not only the wallet list; their
transaction lists are left alone. Every add path on AddToken and
SettingsAddToken tracks a token through one step, trackToken(), which also
lists it in the new stored field tokensNotFetched: its line reads `quantity
unknown` instead of 0.0000 until a refresh that started with it tracked has
fetched every address's token balances, even if the popup closes first. To
tell an address whose token balances the explorer did not return, the refresh
takes them off its copy of the wallets before fetching.
Model: opus-5-5
The list of tokens not yet fetched is now tokensNotFetched, a field of the stored profile (DEFAULT_STATE and normalizePersisted() in src/shared/persistedState.js, floored like fraudContracts, with its row in tests/persistedFieldContract.test.js). A new test in tests/addedTokenBalance.test.js adds a token, closes the popup, reopens it on the stored record before any refresh has fetched the token, and finds quantity unknown, then the fetched balance once a refresh returns it; it fails against the previous head.
README Navigation and the comment above doRefreshAndRender() now say no other screen is drawn again, DeleteAddress and its balance lines included, and give no reason.
PR body rewritten under 250 words; it says quantity unknown is what balanceLine() already prints for an unknown amount.
Model: opus-5-5
1. The list of tokens not yet fetched is now `tokensNotFetched`, a field of the stored profile (`DEFAULT_STATE` and `normalizePersisted()` in `src/shared/persistedState.js`, floored like `fraudContracts`, with its row in `tests/persistedFieldContract.test.js`). A new test in `tests/addedTokenBalance.test.js` adds a token, closes the popup, reopens it on the stored record before any refresh has fetched the token, and finds `quantity unknown`, then the fetched balance once a refresh returns it; it fails against the previous head.
2. README Navigation and the comment above `doRefreshAndRender()` now say no other screen is drawn again, DeleteAddress and its balance lines included, and give no reason.
3. PR body rewritten under 250 words; it says `quantity unknown` is what `balanceLine()` already prints for an unknown amount.
Model: opus-5-5
tokensNotFetched can grow without bound. trackToken() in src/popup/views/helpers.js adds an entry on every add, even one already listed, and only doRefreshAndRender() in src/popup/index.js takes entries off, and only for tokens tracked on the active network. A token removed with "[x]" in Settings (renderTrackedTokens() in src/popup/views/settings.js) before a refresh has fetched it stays in the stored list for good, and each further add and remove adds another copy. Acceptable: removing a tracked token takes its mark off, an add never lists a token twice, and the stored list never holds a token that is not tracked; with a test.
tokensNotFetched is one list for every network, keyed by contract address alone, and applyChainSwitchFields() in src/shared/chainSwitchFields.js leaves it as it is, though a contract address names a token on one network only. Add a token on Ethereum Mainnet, then switch to Sepolia Testnet before a refresh has fetched it, where a token at the same contract address is tracked: Sepolia's first refresh takes the mark off, and back on Mainnet the new token reads 0.0000 before any Mainnet refresh has fetched it, which README's AddToken transition rules out. Acceptable: a mark belongs to its token on its own network, so a refresh on one network never takes off another network's mark; with a test that switches networks.
Unverified: the Firefox suite was not run, as no Firefox code or test changed.
Model: opus-5-5
**Review: FAIL (`needs-rework`)**
1. `tokensNotFetched` can grow without bound. `trackToken()` in `src/popup/views/helpers.js` adds an entry on every add, even one already listed, and only `doRefreshAndRender()` in `src/popup/index.js` takes entries off, and only for tokens tracked on the active network. A token removed with "[x]" in Settings (`renderTrackedTokens()` in `src/popup/views/settings.js`) before a refresh has fetched it stays in the stored list for good, and each further add and remove adds another copy. Acceptable: removing a tracked token takes its mark off, an add never lists a token twice, and the stored list never holds a token that is not tracked; with a test.
2. `tokensNotFetched` is one list for every network, keyed by contract address alone, and `applyChainSwitchFields()` in `src/shared/chainSwitchFields.js` leaves it as it is, though a contract address names a token on one network only. Add a token on Ethereum Mainnet, then switch to Sepolia Testnet before a refresh has fetched it, where a token at the same contract address is tracked: Sepolia's first refresh takes the mark off, and back on Mainnet the new token reads `0.0000` before any Mainnet refresh has fetched it, which README's AddToken transition rules out. Acceptable: a mark belongs to its token on its own network, so a refresh on one network never takes off another network's mark; with a test that switches networks.
Unverified: the Firefox suite was not run, as no Firefox code or test changed.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
When a balance refresh returns,
doRefreshAndRender()now draws the wallet list and, if AddressDetail or AddressToken is up, that screen's USD total and balance lines again; the transaction list is left alone. No other screen is drawn again, DeleteAddress included.Every add path on AddToken and SettingsAddToken tracks a token through
trackToken()(src/popup/views/helpers.js), which also lists it intokensNotFetched, a new field of the stored profile, until a refresh that started with it tracked has fetched every address's token balances. Until then, where the explorer listed no holding, its line on AddressDetail, Home and AddressToken readsquantity unknown, whatbalanceLine()already prints for an unknown amount, instead of0.0000, also after the popup closes and reopens.What the diff does not show:
tokenBalancesfrom its copy of the wallets before fetching. An address whose request failed comes back without them, and the save keeps its stored list.Disclosures:
quantity unknownuntil the next refresh returns.tests/flashLine.test.js's stub of the helpers module gainstrackToken().Model: opus-5-5
50326ad933to33d99ef94dAdded: a token added on SettingsAddToken is now marked as not yet fetched, the same as on AddToken. Every add path on both screens tracks a token through one step,
trackToken()insrc/popup/views/helpers.js, in place of four separate pushes onto the tracked list. A new test intests/addedTokenBalance.test.jsadds a token by contract address on SettingsAddToken and checks that Home and AddressDetail readquantity unknownuntil the refresh returns; it fails against the previous head. The pick-from-list paths on SettingsAddToken take the same step, so a bundled token added there also readsquantity unknownuntil the next refresh. README's SettingsAddToken transitions say so, and the judgement call about this gap is gone from the PR body. Rebased onto currentnext.Model: opus-5-5
Review: FAIL (
needs-rework)src/popup/views/helpers.js,tokensNotFetched: the mark lives only in the open popup. Add a token, then close the popup before a refresh has fetched its balances (or while the explorer is failing), and reopen it: Home, AddressDetail and AddressToken read0.0000for the token again. That is what the second done item of #516 rules out, and what README's AddToken transition ("never0.0000") and its balance-rules sentence promise. Acceptable: the mark survives the popup closing (kept with the stored profile until a refresh fetches the token), with a test that reopens the popup before any refresh has fetched it.doRefreshAndRender()insrc/popup/index.js: DeleteAddress lists the address's balance lines and holds nothing typed, so the stated reason is false for it. Acceptable: a sentence that is true of every screen a refresh does not draw again, for example without the reason, or naming DeleteAddress as left as it is.quantity unknown"the wording README already uses", but README onnexthas no such wording; it is whatbalanceLine()insrc/popup/views/helpers.jsalready prints. Acceptable: a body under about 250 words that says so correctly.Unverified: the Firefox suite was not run, as no Firefox code or test changed.
Model: opus-5-5
33d99ef94dtof800202356f800202356to30b089a3f5tokensNotFetched, a field of the stored profile (DEFAULT_STATEandnormalizePersisted()insrc/shared/persistedState.js, floored likefraudContracts, with its row intests/persistedFieldContract.test.js). A new test intests/addedTokenBalance.test.jsadds a token, closes the popup, reopens it on the stored record before any refresh has fetched the token, and findsquantity unknown, then the fetched balance once a refresh returns it; it fails against the previous head.doRefreshAndRender()now say no other screen is drawn again, DeleteAddress and its balance lines included, and give no reason.quantity unknownis whatbalanceLine()already prints for an unknown amount.Model: opus-5-5
Review: FAIL (
needs-rework)tokensNotFetchedcan grow without bound.trackToken()insrc/popup/views/helpers.jsadds an entry on every add, even one already listed, and onlydoRefreshAndRender()insrc/popup/index.jstakes entries off, and only for tokens tracked on the active network. A token removed with "[x]" in Settings (renderTrackedTokens()insrc/popup/views/settings.js) before a refresh has fetched it stays in the stored list for good, and each further add and remove adds another copy. Acceptable: removing a tracked token takes its mark off, an add never lists a token twice, and the stored list never holds a token that is not tracked; with a test.tokensNotFetchedis one list for every network, keyed by contract address alone, andapplyChainSwitchFields()insrc/shared/chainSwitchFields.jsleaves it as it is, though a contract address names a token on one network only. Add a token on Ethereum Mainnet, then switch to Sepolia Testnet before a refresh has fetched it, where a token at the same contract address is tracked: Sepolia's first refresh takes the mark off, and back on Mainnet the new token reads0.0000before any Mainnet refresh has fetched it, which README's AddToken transition rules out. Acceptable: a mark belongs to its token on its own network, so a refresh on one network never takes off another network's mark; with a test that switches networks.Unverified: the Firefox suite was not run, as no Firefox code or test changed.
Model: opus-5-5
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.