Switching the network in Settings saved it but told no open page, so a connected page kept the old chain id until it asked eth_chainId again. Once the switch is saved, Settings now sends the background an AUTISTMASK_NETWORK_CHANGED message with the new chain id, and the background hands it to broadcastChainChanged(), the function an approved wallet_switchEthereumChain request already uses. The message is in the background's list of popup-only messages, so a web page sending it gets Unauthorized sender and no page is told anything.
Choosing the network already active now returns before switching, so it changes nothing and sends nothing. The selector only fires on a change, so this can only happen when it shows a network other than the one the popup holds.
tests/chainSwitchGate.test.js drives the real Settings view over the background's storage, with what it sends delivered to the real background: one chainChanged with Sepolia's chain id, nothing for the active network, and a page refused. All three fail against current next. The Chrome suite's test page now has to hear both Settings switches, to Sepolia and back.
Judgement call: the chain id travels in the message, as the removed site's origin does for the Settings site list, instead of the background reading it back from storage; the popup-only check is what makes it trusted.
Not done: the Firefox suite has no Settings network case and was not extended.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/AutistMask/issues/500.
Switching the network in Settings saved it but told no open page, so a connected page kept the old chain id until it asked `eth_chainId` again. Once the switch is saved, Settings now sends the background an `AUTISTMASK_NETWORK_CHANGED` message with the new chain id, and the background hands it to `broadcastChainChanged()`, the function an approved `wallet_switchEthereumChain` request already uses. The message is in the background's list of popup-only messages, so a web page sending it gets `Unauthorized sender` and no page is told anything.
Choosing the network already active now returns before switching, so it changes nothing and sends nothing. The selector only fires on a change, so this can only happen when it shows a network other than the one the popup holds.
`tests/chainSwitchGate.test.js` drives the real Settings view over the background's storage, with what it sends delivered to the real background: one `chainChanged` with Sepolia's chain id, nothing for the active network, and a page refused. All three fail against current `next`. The Chrome suite's test page now has to hear both Settings switches, to Sepolia and back.
Judgement call: the chain id travels in the message, as the removed site's origin does for the Settings site list, instead of the background reading it back from storage; the popup-only check is what makes it trusted.
Not done: the Firefox suite has no Settings network case and was not extended.
Model: opus-5-5
Once Settings has saved the new network it asks the background to send
chainChanged with the new chain id to every open tab, through the same
function an approved site switch request uses. Only the extension's own
pages can ask for that. Choosing the network already active changes
nothing and sends nothing.
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.
Fixes #500.
Switching the network in Settings saved it but told no open page, so a connected page kept the old chain id until it asked
eth_chainIdagain. Once the switch is saved, Settings now sends the background anAUTISTMASK_NETWORK_CHANGEDmessage with the new chain id, and the background hands it tobroadcastChainChanged(), the function an approvedwallet_switchEthereumChainrequest already uses. The message is in the background's list of popup-only messages, so a web page sending it getsUnauthorized senderand no page is told anything.Choosing the network already active now returns before switching, so it changes nothing and sends nothing. The selector only fires on a change, so this can only happen when it shows a network other than the one the popup holds.
tests/chainSwitchGate.test.jsdrives the real Settings view over the background's storage, with what it sends delivered to the real background: onechainChangedwith Sepolia's chain id, nothing for the active network, and a page refused. All three fail against currentnext. The Chrome suite's test page now has to hear both Settings switches, to Sepolia and back.Judgement call: the chain id travels in the message, as the removed site's origin does for the Settings site list, instead of the background reading it back from storage; the popup-only check is what makes it trusted.
Not done: the Firefox suite has no Settings network case and was not extended.
Model: opus-5-5
PASS
Model: opus-5-5