[Bug]: Network Switch - Weird screen appears when I trigger the wallet_switchEthereumChain method and pending notification number keeps adding up
#27977
Labels
regression-RC-12.6.0
Regression bug that was found in release candidate (RC) for release 12.6.0
release-12.7.0
Issue or pull request that will be included in release 12.7.0
release-blocker
This bug is blocking the next release
Sev2-normal
Normal severity; minor loss of service or inconvenience.
team-wallet-api-platform
type-bug
Comments
seaona
added
type-bug
Sev1-high
seaona
changed the title
wallet_switchEthereumChain method and pending notification number keeps adding up
seaona
added
Sev2-normal
|
Update: changing the severity to sev 2 as disabling and enabling the wallet clears the pending notifications |
1 similar comment
|
Update: changing the severity to sev 2 as disabling and enabling the wallet clears the pending notifications |
seaona
added
regression-RC-12.8.0
release-blocker
|
This will appear in version |
bschorchit
added
regression-RC-12.6.0
7 tasks
github-merge-queue bot
pushed a commit
that referenced
this issue
Oct 30, 2024
<!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until the template has been completely filled out, and PR status checks have passed at least once. --> ## **Description** Bumps `@metamask/queued-request-controller` to fix queueing issue with Chain Permission `wallet_switchEthereumChain` and `wallet_addEthereumChain` when switching to a previously permitted chain and with `wallet_addEthereumChain` not being enqueued when it still should be. [](https://codespaces.new/MetaMask/metamask-extension/pull/28090?quickstart=1) ## **Related issues** Related: MetaMask/core#4846 Fixes: #28101 Fixes: #27977 ## **Manual testing steps** The easiest way to test this would be a combination of using the test dapp and the following request to switch chains ``` await window.ethereum.request({ "method": "wallet_switchEthereumChain", "params": [ { chainId: "0x1" } ], }); ``` The behaviors you should see include: **One dapp:** * On a dapp permissioned for chain A and B, on chain A, queue up several send transactions, then use wallet_switchEthereumChain to switch to chain B. The send transactions should NOT get cleared immediately after requesting the chain switch. Chain switch should NOT happen until the previous approvals are approved/rejected. * On a dapp permissioned for chain A and B, on chain A, queue up one send transaction, then use wallet_switchEthereumChain to switch to chain B, then queue up several more send transactions. Reject/approve the first transaction. Afterwards, you should see chain B as the active chain for the dapp, and all subsequent approvals cleared/rejected automatically. * On a dapp permissioned for ONLY chain A, on chain A, queue up one send transaction, then use wallet_switchEthereumChain to switch to chain B, then queue up several more send transactions. Reject/approve the first transaction. Afterwards, you should an approval prompt for adding chain B. If you approve it, the dapp should then be on chain B, with all subsequent approvals cleared/rejected. If you disapprove it, you should be prompted with the subsequent approvals. * On a dapp permissioned for ONLY chain A, on chain A, wallet_switchEthereumChain to switch to chain B, then queue up several more send transactions. Reject/approve the first transaction. Afterwards, you should an approval prompt for adding chain B. If you approve it, the dapp should then be on chain B, with all subsequent approvals cleared/rejected. If you disapprove it, you should be prompted with the subsequent approvals. **Two dapps:** * On a dapp permissioned for chain A, on chain A, queue up several send transactions, On a separate dapp permissioned for chain A and B, on chain A, use wallet_switchEthereumChain to switch to chain B. The send transactions should NOT get cleared immediately after requesting the chain switch. Chain switch should NOT happen until the previous approvals are approved/rejected. * On a dapp permissioned for chain A and B, on chain A, queue up one send transaction. On a separate dapp permissioned for chain A and B, on chain A, use wallet_switchEthereumChain to switch to chain B. Then on the first dapp queue up several more send transactions. Reject/approve the first transaction. Afterwards, you should see chain B as the active chain for the second dapp, and then you should still be prompted with the subsequent approvals for the first dapp. * One one dapp, start a wallet_addEthereumChain for a chain that does not exist in the wallet and leave the approval alone. On a different dapp, do the same thing. Only the request from the first dapp should be accessible (i.e. no scrubbing between both of them). After rejecting the first request, the second request should then appear (which will look exactly the same of course). Wallet should not lock up if you repeat this and accept either of the requests ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** https://github.com/user-attachments/assets/2634119f-67db-4866-8520-9320a9400b1d https://github.com/user-attachments/assets/c78c13ab-ea4f-4420-bccc-70959786e8db ## **Pre-merge author checklist** - [ ] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Extension Coding Standards](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/CODING_GUIDELINES.md). - [ ] I've completed the PR template to the best of my ability - [ ] I’ve included tests if applicable - [ ] I’ve documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [ ] I’ve applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. --------- Co-authored-by: MetaMask Bot <metamaskbot@users.noreply.github.com>
metamaskbot
added
the
release-12.7.0
Gudahtt
pushed a commit
that referenced
this issue
Oct 30, 2024
<!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until the template has been completely filled out, and PR status checks have passed at least once. --> Bumps `@metamask/queued-request-controller` to fix queueing issue with Chain Permission `wallet_switchEthereumChain` and `wallet_addEthereumChain` when switching to a previously permitted chain and with `wallet_addEthereumChain` not being enqueued when it still should be. [](https://codespaces.new/MetaMask/metamask-extension/pull/28090?quickstart=1) Related: MetaMask/core#4846 Fixes: #28101 Fixes: #27977 The easiest way to test this would be a combination of using the test dapp and the following request to switch chains ``` await window.ethereum.request({ "method": "wallet_switchEthereumChain", "params": [ { chainId: "0x1" } ], }); ``` The behaviors you should see include: **One dapp:** * On a dapp permissioned for chain A and B, on chain A, queue up several send transactions, then use wallet_switchEthereumChain to switch to chain B. The send transactions should NOT get cleared immediately after requesting the chain switch. Chain switch should NOT happen until the previous approvals are approved/rejected. * On a dapp permissioned for chain A and B, on chain A, queue up one send transaction, then use wallet_switchEthereumChain to switch to chain B, then queue up several more send transactions. Reject/approve the first transaction. Afterwards, you should see chain B as the active chain for the dapp, and all subsequent approvals cleared/rejected automatically. * On a dapp permissioned for ONLY chain A, on chain A, queue up one send transaction, then use wallet_switchEthereumChain to switch to chain B, then queue up several more send transactions. Reject/approve the first transaction. Afterwards, you should an approval prompt for adding chain B. If you approve it, the dapp should then be on chain B, with all subsequent approvals cleared/rejected. If you disapprove it, you should be prompted with the subsequent approvals. * On a dapp permissioned for ONLY chain A, on chain A, wallet_switchEthereumChain to switch to chain B, then queue up several more send transactions. Reject/approve the first transaction. Afterwards, you should an approval prompt for adding chain B. If you approve it, the dapp should then be on chain B, with all subsequent approvals cleared/rejected. If you disapprove it, you should be prompted with the subsequent approvals. **Two dapps:** * On a dapp permissioned for chain A, on chain A, queue up several send transactions, On a separate dapp permissioned for chain A and B, on chain A, use wallet_switchEthereumChain to switch to chain B. The send transactions should NOT get cleared immediately after requesting the chain switch. Chain switch should NOT happen until the previous approvals are approved/rejected. * On a dapp permissioned for chain A and B, on chain A, queue up one send transaction. On a separate dapp permissioned for chain A and B, on chain A, use wallet_switchEthereumChain to switch to chain B. Then on the first dapp queue up several more send transactions. Reject/approve the first transaction. Afterwards, you should see chain B as the active chain for the second dapp, and then you should still be prompted with the subsequent approvals for the first dapp. * One one dapp, start a wallet_addEthereumChain for a chain that does not exist in the wallet and leave the approval alone. On a different dapp, do the same thing. Only the request from the first dapp should be accessible (i.e. no scrubbing between both of them). After rejecting the first request, the second request should then appear (which will look exactly the same of course). Wallet should not lock up if you repeat this and accept either of the requests <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> <!-- [screenshots/recordings] --> https://github.com/user-attachments/assets/2634119f-67db-4866-8520-9320a9400b1d https://github.com/user-attachments/assets/c78c13ab-ea4f-4420-bccc-70959786e8db - [ ] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Extension Coding Standards](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/CODING_GUIDELINES.md). - [ ] I've completed the PR template to the best of my ability - [ ] I’ve included tests if applicable - [ ] I’ve documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [ ] I’ve applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. --------- Co-authored-by: MetaMask Bot <metamaskbot@users.noreply.github.com>
7 tasks
Gudahtt
pushed a commit
that referenced
this issue
Oct 30, 2024
<!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until the template has been completely filled out, and PR status checks have passed at least once. --> Bumps `@metamask/queued-request-controller` to fix queueing issue with Chain Permission `wallet_switchEthereumChain` and `wallet_addEthereumChain` when switching to a previously permitted chain and with `wallet_addEthereumChain` not being enqueued when it still should be. [](https://codespaces.new/MetaMask/metamask-extension/pull/28090?quickstart=1) Related: MetaMask/core#4846 Fixes: #28101 Fixes: #27977 The easiest way to test this would be a combination of using the test dapp and the following request to switch chains ``` await window.ethereum.request({ "method": "wallet_switchEthereumChain", "params": [ { chainId: "0x1" } ], }); ``` The behaviors you should see include: **One dapp:** * On a dapp permissioned for chain A and B, on chain A, queue up several send transactions, then use wallet_switchEthereumChain to switch to chain B. The send transactions should NOT get cleared immediately after requesting the chain switch. Chain switch should NOT happen until the previous approvals are approved/rejected. * On a dapp permissioned for chain A and B, on chain A, queue up one send transaction, then use wallet_switchEthereumChain to switch to chain B, then queue up several more send transactions. Reject/approve the first transaction. Afterwards, you should see chain B as the active chain for the dapp, and all subsequent approvals cleared/rejected automatically. * On a dapp permissioned for ONLY chain A, on chain A, queue up one send transaction, then use wallet_switchEthereumChain to switch to chain B, then queue up several more send transactions. Reject/approve the first transaction. Afterwards, you should an approval prompt for adding chain B. If you approve it, the dapp should then be on chain B, with all subsequent approvals cleared/rejected. If you disapprove it, you should be prompted with the subsequent approvals. * On a dapp permissioned for ONLY chain A, on chain A, wallet_switchEthereumChain to switch to chain B, then queue up several more send transactions. Reject/approve the first transaction. Afterwards, you should an approval prompt for adding chain B. If you approve it, the dapp should then be on chain B, with all subsequent approvals cleared/rejected. If you disapprove it, you should be prompted with the subsequent approvals. **Two dapps:** * On a dapp permissioned for chain A, on chain A, queue up several send transactions, On a separate dapp permissioned for chain A and B, on chain A, use wallet_switchEthereumChain to switch to chain B. The send transactions should NOT get cleared immediately after requesting the chain switch. Chain switch should NOT happen until the previous approvals are approved/rejected. * On a dapp permissioned for chain A and B, on chain A, queue up one send transaction. On a separate dapp permissioned for chain A and B, on chain A, use wallet_switchEthereumChain to switch to chain B. Then on the first dapp queue up several more send transactions. Reject/approve the first transaction. Afterwards, you should see chain B as the active chain for the second dapp, and then you should still be prompted with the subsequent approvals for the first dapp. * One one dapp, start a wallet_addEthereumChain for a chain that does not exist in the wallet and leave the approval alone. On a different dapp, do the same thing. Only the request from the first dapp should be accessible (i.e. no scrubbing between both of them). After rejecting the first request, the second request should then appear (which will look exactly the same of course). Wallet should not lock up if you repeat this and accept either of the requests <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> <!-- [screenshots/recordings] --> https://github.com/user-attachments/assets/2634119f-67db-4866-8520-9320a9400b1d https://github.com/user-attachments/assets/c78c13ab-ea4f-4420-bccc-70959786e8db - [ ] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Extension Coding Standards](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/CODING_GUIDELINES.md). - [ ] I've completed the PR template to the best of my ability - [ ] I’ve included tests if applicable - [ ] I’ve documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [ ] I’ve applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. --------- Co-authored-by: MetaMask Bot <metamaskbot@users.noreply.github.com>
Gudahtt
pushed a commit
that referenced
this issue
Oct 30, 2024
<!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until the template has been completely filled out, and PR status checks have passed at least once. --> Bumps `@metamask/queued-request-controller` to fix queueing issue with Chain Permission `wallet_switchEthereumChain` and `wallet_addEthereumChain` when switching to a previously permitted chain and with `wallet_addEthereumChain` not being enqueued when it still should be. [](https://codespaces.new/MetaMask/metamask-extension/pull/28090?quickstart=1) Related: MetaMask/core#4846 Fixes: #28101 Fixes: #27977 The easiest way to test this would be a combination of using the test dapp and the following request to switch chains ``` await window.ethereum.request({ "method": "wallet_switchEthereumChain", "params": [ { chainId: "0x1" } ], }); ``` The behaviors you should see include: **One dapp:** * On a dapp permissioned for chain A and B, on chain A, queue up several send transactions, then use wallet_switchEthereumChain to switch to chain B. The send transactions should NOT get cleared immediately after requesting the chain switch. Chain switch should NOT happen until the previous approvals are approved/rejected. * On a dapp permissioned for chain A and B, on chain A, queue up one send transaction, then use wallet_switchEthereumChain to switch to chain B, then queue up several more send transactions. Reject/approve the first transaction. Afterwards, you should see chain B as the active chain for the dapp, and all subsequent approvals cleared/rejected automatically. * On a dapp permissioned for ONLY chain A, on chain A, queue up one send transaction, then use wallet_switchEthereumChain to switch to chain B, then queue up several more send transactions. Reject/approve the first transaction. Afterwards, you should an approval prompt for adding chain B. If you approve it, the dapp should then be on chain B, with all subsequent approvals cleared/rejected. If you disapprove it, you should be prompted with the subsequent approvals. * On a dapp permissioned for ONLY chain A, on chain A, wallet_switchEthereumChain to switch to chain B, then queue up several more send transactions. Reject/approve the first transaction. Afterwards, you should an approval prompt for adding chain B. If you approve it, the dapp should then be on chain B, with all subsequent approvals cleared/rejected. If you disapprove it, you should be prompted with the subsequent approvals. **Two dapps:** * On a dapp permissioned for chain A, on chain A, queue up several send transactions, On a separate dapp permissioned for chain A and B, on chain A, use wallet_switchEthereumChain to switch to chain B. The send transactions should NOT get cleared immediately after requesting the chain switch. Chain switch should NOT happen until the previous approvals are approved/rejected. * On a dapp permissioned for chain A and B, on chain A, queue up one send transaction. On a separate dapp permissioned for chain A and B, on chain A, use wallet_switchEthereumChain to switch to chain B. Then on the first dapp queue up several more send transactions. Reject/approve the first transaction. Afterwards, you should see chain B as the active chain for the second dapp, and then you should still be prompted with the subsequent approvals for the first dapp. * One one dapp, start a wallet_addEthereumChain for a chain that does not exist in the wallet and leave the approval alone. On a different dapp, do the same thing. Only the request from the first dapp should be accessible (i.e. no scrubbing between both of them). After rejecting the first request, the second request should then appear (which will look exactly the same of course). Wallet should not lock up if you repeat this and accept either of the requests <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> <!-- [screenshots/recordings] --> https://github.com/user-attachments/assets/2634119f-67db-4866-8520-9320a9400b1d https://github.com/user-attachments/assets/c78c13ab-ea4f-4420-bccc-70959786e8db - [ ] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Extension Coding Standards](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/CODING_GUIDELINES.md). - [ ] I've completed the PR template to the best of my ability - [ ] I’ve included tests if applicable - [ ] I’ve documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [ ] I’ve applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. --------- Co-authored-by: MetaMask Bot <metamaskbot@users.noreply.github.com>
Gudahtt
added a commit
that referenced
this issue
Oct 30, 2024
This is a cherry-pick of #28090 for v12.6.0. Original description: <!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until the template has been completely filled out, and PR status checks have passed at least once. --> ## **Description** Bumps `@metamask/queued-request-controller` to fix queueing issue with Chain Permission `wallet_switchEthereumChain` and `wallet_addEthereumChain` when switching to a previously permitted chain and with `wallet_addEthereumChain` not being enqueued when it still should be. [](https://codespaces.new/MetaMask/metamask-extension/pull/28090?quickstart=1) ## **Related issues** Related: MetaMask/core#4846 Fixes: #28101 Fixes: #27977 Fixes: #28102 ## **Manual testing steps** The easiest way to test this would be a combination of using the test dapp and the following request to switch chains ``` await window.ethereum.request({ "method": "wallet_switchEthereumChain", "params": [ { chainId: "0x1" } ], }); ``` The behaviors you should see include: **One dapp:** * On a dapp permissioned for chain A and B, on chain A, queue up several send transactions, then use wallet_switchEthereumChain to switch to chain B. The send transactions should NOT get cleared immediately after requesting the chain switch. Chain switch should NOT happen until the previous approvals are approved/rejected. * On a dapp permissioned for chain A and B, on chain A, queue up one send transaction, then use wallet_switchEthereumChain to switch to chain B, then queue up several more send transactions. Reject/approve the first transaction. Afterwards, you should see chain B as the active chain for the dapp, and all subsequent approvals cleared/rejected automatically. * On a dapp permissioned for ONLY chain A, on chain A, queue up one send transaction, then use wallet_switchEthereumChain to switch to chain B, then queue up several more send transactions. Reject/approve the first transaction. Afterwards, you should an approval prompt for adding chain B. If you approve it, the dapp should then be on chain B, with all subsequent approvals cleared/rejected. If you disapprove it, you should be prompted with the subsequent approvals. * On a dapp permissioned for ONLY chain A, on chain A, wallet_switchEthereumChain to switch to chain B, then queue up several more send transactions. Reject/approve the first transaction. Afterwards, you should an approval prompt for adding chain B. If you approve it, the dapp should then be on chain B, with all subsequent approvals cleared/rejected. If you disapprove it, you should be prompted with the subsequent approvals. **Two dapps:** * On a dapp permissioned for chain A, on chain A, queue up several send transactions, On a separate dapp permissioned for chain A and B, on chain A, use wallet_switchEthereumChain to switch to chain B. The send transactions should NOT get cleared immediately after requesting the chain switch. Chain switch should NOT happen until the previous approvals are approved/rejected. * On a dapp permissioned for chain A and B, on chain A, queue up one send transaction. On a separate dapp permissioned for chain A and B, on chain A, use wallet_switchEthereumChain to switch to chain B. Then on the first dapp queue up several more send transactions. Reject/approve the first transaction. Afterwards, you should see chain B as the active chain for the second dapp, and then you should still be prompted with the subsequent approvals for the first dapp. * One one dapp, start a wallet_addEthereumChain for a chain that does not exist in the wallet and leave the approval alone. On a different dapp, do the same thing. Only the request from the first dapp should be accessible (i.e. no scrubbing between both of them). After rejecting the first request, the second request should then appear (which will look exactly the same of course). Wallet should not lock up if you repeat this and accept either of the requests ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** https://github.com/user-attachments/assets/2634119f-67db-4866-8520-9320a9400b1d https://github.com/user-attachments/assets/c78c13ab-ea4f-4420-bccc-70959786e8db ## **Pre-merge author checklist** - [ ] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Extension Coding Standards](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/CODING_GUIDELINES.md). - [ ] I've completed the PR template to the best of my ability - [ ] I’ve included tests if applicable - [ ] I’ve documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [ ] I’ve applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. --------- Co-authored-by: jiexi <jiexiluan@gmail.com> Co-authored-by: MetaMask Bot <metamaskbot@users.noreply.github.com>
](https://codespaces.new/MetaMask/metamask-extension/pull/28090?quickstart=1){kind=link}
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
The classical weird screen appears when I trigger a
wallet_switchEthereumChainmethod on a second dapp, after triggering a signature and awallet_switchEthereumChainon a first dapp . The notification number keeps adding up in the MM icon, no matter if I close the screen.The recovery path is to click the reload button from the Extension.
Expected behavior
Screenshots/Recordings
weitd-screen.mp4
Steps to reproduce
Error messages or log output
No response
Detection stage
On the development branch
Version
last develop (oct 21st) - commit 4eaeb68
Build type
None
Browser
Chrome
Operating system
Linux
Hardware wallet
No response
Additional context
No response
Severity
No response
The text was updated successfully, but these errors were encountered: