"Back" from AddressToken now clears the selected token, so AddressDetail, Send and Receive start with none.
"Back" also puts Send's dropdown on ETH. AddressToken's "Send" sets the dropdown to the token, and nothing rebuilds it on the way back. A dropdown with no option for that token reads empty, and Send would now use that empty value.
What the diff does not show:
After "Back", "Done" on a send started from AddressDetail returns to AddressDetail. It used to open AddressToken.
A transaction list still loading when "Back" is tapped now stops at its existing check, so it saves no newly found fraud contract. AddressDetail's own list makes the same save.
Disclosures:
Not fixed: three other routes still reach Home with the token selected, and Home's "Send" then uses that token whatever the dropdown shows. I ran each with a test I did not commit. The fix for them is outside addressToken.js, so I left them for a decision:
reopening the popup after AddressToken's "Send";
the Settings gear on AddressToken, then adding a wallet;
the Settings gear on AddressToken, then deleting another wallet, then "Back".
The three tests under "Send opened from AddressToken sends that token" also pass on next. They guard behaviour the fix must keep, and each fails when Send is made to use another token.
The empty dropdown comes from the HTML standard and was not run in a browser.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/AutistMask/issues/751.
"Back" from AddressToken now clears the selected token, so AddressDetail, Send and Receive start with none.
"Back" also puts Send's dropdown on ETH. AddressToken's "Send" sets the dropdown to the token, and nothing rebuilds it on the way back. A dropdown with no option for that token reads empty, and Send would now use that empty value.
What the diff does not show:
- After "Back", "Done" on a send started from AddressDetail returns to AddressDetail. It used to open AddressToken.
- A transaction list still loading when "Back" is tapped now stops at its existing check, so it saves no newly found fraud contract. AddressDetail's own list makes the same save.
Disclosures:
- Not fixed: three other routes still reach Home with the token selected, and Home's "Send" then uses that token whatever the dropdown shows. I ran each with a test I did not commit. The fix for them is outside `addressToken.js`, so I left them for a decision:
- reopening the popup after AddressToken's "Send";
- the Settings gear on AddressToken, then adding a wallet;
- the Settings gear on AddressToken, then deleting another wallet, then "Back".
- The three tests under "Send opened from AddressToken sends that token" also pass on `next`. They guard behaviour the fix must keep, and each fails when Send is made to use another token.
- The empty dropdown comes from the HTML standard and was not run in a browser.
Model: opus-5-5
AddressDetail's show() clears the token, but "Back" onto a screen already drawn
only unhides it. Send and Receive then kept using the token from AddressToken,
whatever Send's dropdown showed. "Back" now clears the token and puts the
dropdown on ETH.
Model: opus-5-5
Passed: "Back" from AddressToken clears the selected token and puts Send's dropdown on ETH, as #751 asks.
Follow-up: no open issue tracks the three routes this PR lists as not fixed. On them, Home's "Send" opens with the dropdown on ETH and reviews the selected token. Home's "Receive" reads the same field, so it can show that token's warning. Acceptable: a new issue whose fix clears state.selectedToken when Home's "Send" and "Receive" open (src/popup/views/home.js).
Unverified: I ran the route that reopens the popup, and read the other two routes and Home's "Receive" from the code.
Unverified: a dropdown with no option for the token reading empty was not run in a browser. It rests on the HTML standard, as this PR says.
Model: opus-5-5
Passed: "Back" from AddressToken clears the selected token and puts Send's dropdown on ETH, as https://git.eeqj.de/sneak/AutistMask/issues/751 asks.
- Follow-up: no open issue tracks the three routes this PR lists as not fixed. On them, Home's "Send" opens with the dropdown on ETH and reviews the selected token. Home's "Receive" reads the same field, so it can show that token's warning. Acceptable: a new issue whose fix clears `state.selectedToken` when Home's "Send" and "Receive" open (`src/popup/views/home.js`).
- Unverified: I ran the route that reopens the popup, and read the other two routes and Home's "Receive" from the code.
- Unverified: a dropdown with no option for the token reading empty was not run in a browser. It rests on the HTML standard, as this PR says.
Model: opus-5-5
clawbot
merged commit e438272125 into next2026-11-03 15:27:41 +01:00
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.
Fixes #751.
"Back" from AddressToken now clears the selected token, so AddressDetail, Send and Receive start with none.
"Back" also puts Send's dropdown on ETH. AddressToken's "Send" sets the dropdown to the token, and nothing rebuilds it on the way back. A dropdown with no option for that token reads empty, and Send would now use that empty value.
What the diff does not show:
Disclosures:
addressToken.js, so I left them for a decision:next. They guard behaviour the fix must keep, and each fails when Send is made to use another token.Model: opus-5-5
Passed: "Back" from AddressToken clears the selected token and puts Send's dropdown on ETH, as #751 asks.
state.selectedTokenwhen Home's "Send" and "Receive" open (src/popup/views/home.js).Model: opus-5-5