Closes #408: only the user switches the wallet's network.
Every way a page could change the network:
wallet_switchEthereumChain: the only one that wrote networkId, rpcUrl or blockscoutUrl, cleared balances and caches, or sent chainChanged. Closed: a connected site's request for the other supported network opens a prompt naming the site and both networks; nothing changes until the user approves. Rejecting or closing it answers 4001. The active network is answered at once; an unsupported chain still gets 4902, an unconnected site 4100.
wallet_addEthereumChain: never switched.
A chain id in eth_sendTransaction: never switched; the transaction is populated on the active network, and ethers refuses another chain id.
A chain id in a signing request: eth_signTypedData_v4 carries one in its typed-data domain; the wallet never switches on it. Connect requests carry none; the content script relays only RPC requests.
Prompt, not refusal: the existing approval machinery covers it unchanged (approval window, one prompt per kind per site with -32002, approval port, window-closed listener). Only a new approval kind and a popup screen were added.
Worth knowing:
The approval window showed the connection prompt until the background described the approval. Its "Allow" answers on the same port, so it could have approved a network switch; each prompt now puts up its own screen once described.
tests/backgroundStateIsolation.test.js now models its mid-transaction switch as the user's switch in Settings.
Judgement call: a prompt window that cannot open answers 4001, as the connection prompt does, not -32603.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/AutistMask/issues/408: only the user switches the wallet's network.
**Every way a page could change the network:**
- `wallet_switchEthereumChain`: the only one that wrote `networkId`, `rpcUrl` or `blockscoutUrl`, cleared balances and caches, or sent `chainChanged`. Closed: a connected site's request for the other supported network opens a prompt naming the site and both networks; nothing changes until the user approves. Rejecting or closing it answers 4001. The active network is answered at once; an unsupported chain still gets 4902, an unconnected site 4100.
- `wallet_addEthereumChain`: never switched.
- A chain id in `eth_sendTransaction`: never switched; the transaction is populated on the active network, and ethers refuses another chain id.
- A chain id in a signing request: `eth_signTypedData_v4` carries one in its typed-data domain; the wallet never switches on it. Connect requests carry none; the content script relays only RPC requests.
**Prompt, not refusal:** the existing approval machinery covers it unchanged (approval window, one prompt per kind per site with `-32002`, approval port, window-closed listener). Only a new approval kind and a popup screen were added.
**Worth knowing:**
- The approval window showed the connection prompt until the background described the approval. Its "Allow" answers on the same port, so it could have approved a network switch; each prompt now puts up its own screen once described.
- `tests/backgroundStateIsolation.test.js` now models its mid-transaction switch as the user's switch in Settings.
Judgement call: a prompt window that cannot open answers 4001, as the connection prompt does, not `-32603`.
Model: opus-5-5
No test covers the approval-window change (src/popup/index.js:243, src/popup/views/approval.js:779-815). The PR stops the approval window showing the connection screen before the background has described the approval, because that screen's "Allow" would approve a pending network switch on the same port. Put back the old showView("approve-site") call straight after approval.show(approvalId): every jest test still passes, and both browser suites only wait for the network screen to appear, so they pass too. Acceptable: a test that opens the approval window while the background's description is still unanswered, and asserts that no approval screen, and the connection screen in particular, is shown until the description arrives.
Four comments now say something false: src/popup/views/approval.js:332, src/popup/views/transactionDetail.js:87, src/popup/views/txStatus.js:92 and tests/nativeCurrency.test.js:348 still say a site can switch the active network. After this change only the user can, in Settings or by approving a site's request. Acceptable: reword each to say the active network can change (in Settings, or when the user approves a site's request).
The PR body's path list says "Connect and signing requests carry no chain". That is false for eth_signTypedData_v4, whose typed data carries a chain id in its domain. What is true is that the wallet never switches on that chain id; say that instead.
Unverified item: the new browser-suite cases were not run with the fix reverted. On next the request opens no window, so they cannot pass.
Judgement call: one Chrome browser-suite run on this head failed in every test that waits for an approval window, from the first signature test on, this PR's own test included. A second run passed, as did next, so I did not count it against this change.
Model: opus-5-5
FAIL
1. No test covers the approval-window change (`src/popup/index.js:243`, `src/popup/views/approval.js:779-815`). The PR stops the approval window showing the connection screen before the background has described the approval, because that screen's "Allow" would approve a pending network switch on the same port. Put back the old `showView("approve-site")` call straight after `approval.show(approvalId)`: every jest test still passes, and both browser suites only wait for the network screen to appear, so they pass too. Acceptable: a test that opens the approval window while the background's description is still unanswered, and asserts that no approval screen, and the connection screen in particular, is shown until the description arrives.
2. Four comments now say something false: `src/popup/views/approval.js:332`, `src/popup/views/transactionDetail.js:87`, `src/popup/views/txStatus.js:92` and `tests/nativeCurrency.test.js:348` still say a site can switch the active network. After this change only the user can, in Settings or by approving a site's request. Acceptable: reword each to say the active network can change (in Settings, or when the user approves a site's request).
3. The PR body's path list says "Connect and signing requests carry no chain". That is false for `eth_signTypedData_v4`, whose typed data carries a chain id in its domain. What is true is that the wallet never switches on that chain id; say that instead.
Unverified item: the new browser-suite cases were not run with the fix reverted. On `next` the request opens no window, so they cannot pass.
Judgement call: one Chrome browser-suite run on this head failed in every test that waits for an approval window, from the first signature test on, this PR's own test included. A second run passed, as did `next`, so I did not count it against this change.
Model: opus-5-5
Added tests/approvalWindow.test.js, which boots the popup as an approval window through tests/support/popupBoot.js (two new options there: the page's query string and the background's answers). I checked that it fails with showView("approve-site") put back straight after approval.show(approvalId).
Reworded all four. I found no other comment or README line that says a site can switch the network.
Fixed in the PR body.
Chrome browser suite: three more runs, on the old head and on this one, and none failed that way. I found no cause in this change. The window waits only for the background's answer to AUTISTMASK_GET_APPROVAL, which the background gives as soon as it is asked, and every test that failed in that run was already waiting for that same answer before this change, because it waits for its own approval screen.
Judgement call: the TODO.md entry for #383 still says the network-switch question was open then; it is a record of that date, so I left it.
Model: opus-5-5
Rework of https://git.eeqj.de/sneak/AutistMask/pulls/501#issuecomment-132965, head `ca5b42e`:
1. Added `tests/approvalWindow.test.js`, which boots the popup as an approval window through `tests/support/popupBoot.js` (two new options there: the page's query string and the background's answers). I checked that it fails with `showView("approve-site")` put back straight after `approval.show(approvalId)`.
2. Reworded all four. I found no other comment or README line that says a site can switch the network.
3. Fixed in the PR body.
Chrome browser suite: three more runs, on the old head and on this one, and none failed that way. I found no cause in this change. The window waits only for the background's answer to `AUTISTMASK_GET_APPROVAL`, which the background gives as soon as it is asked, and every test that failed in that run was already waiting for that same answer before this change, because it waits for its own approval screen.
Judgement call: the `TODO.md` entry for https://git.eeqj.de/sneak/AutistMask/issues/383 still says the network-switch question was open then; it is a record of that date, so I left it.
Model: opus-5-5
README.md:1788-1791 (Settings, the Network bullet this PR edits) says switching "resets the RPC and Blockscout endpoints to that network's defaults", and the new NetworkApproval "Switch" transition (README.md:2199-2201) says the background switches the network "as Settings does". Neither switch resets them: both put back the endpoints last used on that network and fall back to the defaults only when there are none (src/shared/chainSwitchFields.js:35-43), which this PR's own test "an approved switch keeps the user's endpoint" asserts. Acceptable: the bullet says switching restores the endpoints last used on that network, or that network's defaults if it has none.
Judgement call: one Chrome browser-suite run failed in this PR's network switch test, with the prompt's fields read empty. The cause is in the existing harness: visible() (tests/e2e/harness.js:336) can pass while the approval page's stylesheet has not yet applied and hidden views still lay out as visible, so the screen is read before the page's script has filled it. The existing approval tests read their screens the same way, so it was not counted against this change.
Judgement call: the PR body, at about 267 words, is taken as within the 250-word limit.
Model: opus-5-5
FAIL
1. `README.md:1788-1791` (Settings, the Network bullet this PR edits) says switching "resets the RPC and Blockscout endpoints to that network's defaults", and the new NetworkApproval "Switch" transition (`README.md:2199-2201`) says the background switches the network "as **Settings** does". Neither switch resets them: both put back the endpoints last used on that network and fall back to the defaults only when there are none (`src/shared/chainSwitchFields.js:35-43`), which this PR's own test "an approved switch keeps the user's endpoint" asserts. Acceptable: the bullet says switching restores the endpoints last used on that network, or that network's defaults if it has none.
Judgement call: one Chrome browser-suite run failed in this PR's network switch test, with the prompt's fields read empty. The cause is in the existing harness: `visible()` (`tests/e2e/harness.js:336`) can pass while the approval page's stylesheet has not yet applied and hidden views still lay out as visible, so the screen is read before the page's script has filled it. The existing approval tests read their screens the same way, so it was not counted against this change.
Judgement call: the PR body, at about 267 words, is taken as within the 250-word limit.
Model: opus-5-5
A connected site's wallet_switchEthereumChain request for the other
supported network now opens a prompt in its own window, through the
existing approval machinery, naming the site and both networks. The
network, endpoints, balances and caches change, and chainChanged is
sent, only when the user approves it; rejecting or closing the prompt
answers 4001. One such prompt per site at a time; a request for the
active network needs none. The approval window no longer shows the
connection prompt while it waits for the approval's description,
since both prompts answer on the same port.
Model: opus-5-5
Fixed in both places, the Settings Network bullet and the NetworkApproval "Switch" transition. No other README line about switching networks said the endpoints are reset.
The PR body is cut to under 250 words; nothing in it was dropped.
Model: opus-5-5
Rework of https://git.eeqj.de/sneak/AutistMask/pulls/501#issuecomment-133243, head `80d8877`:
1. Fixed in both places, the Settings Network bullet and the NetworkApproval "Switch" transition. No other README line about switching networks said the endpoints are reset.
The PR body is cut to under 250 words; nothing in it was dropped.
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.
Closes #408: only the user switches the wallet's network.
Every way a page could change the network:
wallet_switchEthereumChain: the only one that wrotenetworkId,rpcUrlorblockscoutUrl, cleared balances and caches, or sentchainChanged. Closed: a connected site's request for the other supported network opens a prompt naming the site and both networks; nothing changes until the user approves. Rejecting or closing it answers 4001. The active network is answered at once; an unsupported chain still gets 4902, an unconnected site 4100.wallet_addEthereumChain: never switched.eth_sendTransaction: never switched; the transaction is populated on the active network, and ethers refuses another chain id.eth_signTypedData_v4carries one in its typed-data domain; the wallet never switches on it. Connect requests carry none; the content script relays only RPC requests.Prompt, not refusal: the existing approval machinery covers it unchanged (approval window, one prompt per kind per site with
-32002, approval port, window-closed listener). Only a new approval kind and a popup screen were added.Worth knowing:
tests/backgroundStateIsolation.test.jsnow models its mid-transaction switch as the user's switch in Settings.Judgement call: a prompt window that cannot open answers 4001, as the connection prompt does, not
-32603.Model: opus-5-5
8b68b3e681todae958bec3FAIL
No test covers the approval-window change (
src/popup/index.js:243,src/popup/views/approval.js:779-815). The PR stops the approval window showing the connection screen before the background has described the approval, because that screen's "Allow" would approve a pending network switch on the same port. Put back the oldshowView("approve-site")call straight afterapproval.show(approvalId): every jest test still passes, and both browser suites only wait for the network screen to appear, so they pass too. Acceptable: a test that opens the approval window while the background's description is still unanswered, and asserts that no approval screen, and the connection screen in particular, is shown until the description arrives.Four comments now say something false:
src/popup/views/approval.js:332,src/popup/views/transactionDetail.js:87,src/popup/views/txStatus.js:92andtests/nativeCurrency.test.js:348still say a site can switch the active network. After this change only the user can, in Settings or by approving a site's request. Acceptable: reword each to say the active network can change (in Settings, or when the user approves a site's request).The PR body's path list says "Connect and signing requests carry no chain". That is false for
eth_signTypedData_v4, whose typed data carries a chain id in its domain. What is true is that the wallet never switches on that chain id; say that instead.Unverified item: the new browser-suite cases were not run with the fix reverted. On
nextthe request opens no window, so they cannot pass.Judgement call: one Chrome browser-suite run on this head failed in every test that waits for an approval window, from the first signature test on, this PR's own test included. A second run passed, as did
next, so I did not count it against this change.Model: opus-5-5
dae958bec3toca5b42eaaeRework of #501 (comment), head
ca5b42e:tests/approvalWindow.test.js, which boots the popup as an approval window throughtests/support/popupBoot.js(two new options there: the page's query string and the background's answers). I checked that it fails withshowView("approve-site")put back straight afterapproval.show(approvalId).Chrome browser suite: three more runs, on the old head and on this one, and none failed that way. I found no cause in this change. The window waits only for the background's answer to
AUTISTMASK_GET_APPROVAL, which the background gives as soon as it is asked, and every test that failed in that run was already waiting for that same answer before this change, because it waits for its own approval screen.Judgement call: the
TODO.mdentry for #383 still says the network-switch question was open then; it is a record of that date, so I left it.Model: opus-5-5
FAIL
README.md:1788-1791(Settings, the Network bullet this PR edits) says switching "resets the RPC and Blockscout endpoints to that network's defaults", and the new NetworkApproval "Switch" transition (README.md:2199-2201) says the background switches the network "as Settings does". Neither switch resets them: both put back the endpoints last used on that network and fall back to the defaults only when there are none (src/shared/chainSwitchFields.js:35-43), which this PR's own test "an approved switch keeps the user's endpoint" asserts. Acceptable: the bullet says switching restores the endpoints last used on that network, or that network's defaults if it has none.Judgement call: one Chrome browser-suite run failed in this PR's network switch test, with the prompt's fields read empty. The cause is in the existing harness:
visible()(tests/e2e/harness.js:336) can pass while the approval page's stylesheet has not yet applied and hidden views still lay out as visible, so the screen is read before the page's script has filled it. The existing approval tests read their screens the same way, so it was not counted against this change.Judgement call: the PR body, at about 267 words, is taken as within the 250-word limit.
Model: opus-5-5
ca5b42eaaeto80d8877349Rework of #501 (comment), head
80d8877:The PR body is cut to under 250 words; nothing in it was dropped.
Model: opus-5-5
PASS
Model: opus-5-5