-
Notifications
You must be signed in to change notification settings - Fork 5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: Bring popup to the foreground functionality is not working as expected. #25397
Comments
To be clear here, subsequent requests in steps 4 and 5 should cause a popup that shows the pending confirmation from step 2 to show up |
@sleepytanya @jiexi To make sure I understand the issue, is this right? GIVEN A pending transaction request It looks like the confirmation from step 2 is shown when opening MM manually, but expected is for the popup to open automatically. Is that right? |
@hesterbruikman Right! You can also reject unapproved transaction from the homepage. But if you reject from there the next request will be displayed in fullscreen: Screen.Recording.2024-06-18.at.17.35.28.mov@hesterbruikman Also while at the full screen homepage MM sometimes breaks with an error: |
ℹ️ I've added repro steps for the |
Latest build [https://github.com/MetaMask/metamask-extension/commit/eebc4d5b2284024eaeb190cddfa89990f593ca34] Popup behavior didn't change:
connectTxTx.movScreen.Recording.2024-06-20.at.17.43.05.mov |
Findings thus far:
|
There's a separate issue for balance destructuring issues. |
The issue is the QueuedRequestController will only allow requests to continue on to the ApprovalController if all currently unapproved transactions belong to the same networkClientId. Once a request (that requires confirmation) is received for a networkClientId that differs from the current set of unapproved transactions, that transaction and all transactions afterward (including those matching the original networkClientId with unapproved transactions still visible and scrubbable by the user) are held in the request queue until the current set of unapproved transactions for the first networkClientId are approved/rejected. This means that the notification window will not be focused starting with the first transaction that differs from the existing unapproved transactions batch. I believe the fix here is to expose the |
@jiexi is my understanding correct that your PR fixes the issue: Popup does not appear when a new confirmation request is received, for a If so it seems like we can close this issue when your PR gets merged. There might be residual work related to queue batches not represented clearly in the UI, but that seems like a larger project and out of scope for v12. cc @darkwing |
…onfirmation popup focus in request queue (#25497) <!-- 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** <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> [![Open in GitHub Codespaces](https://github.com/codespaces/badge.svg)](https://codespaces.new/MetaMask/metamask-extension/pull/25497?quickstart=1) ## **Related issues** See: MetaMask/core#4457 See: #25397 ## **Manual testing steps** 1. Ensure request queue is toggled on 2. In Tab 1, Visit the test dapp 3. run `await window.ethereum.request({method: 'wallet_switchEthereumChain', params: [{"chainId": "0xaa36a7"}]})` in console to change the network to sepolia for this dapp 4. In Tab 2, Visit a different dapp 5. run `await window.ethereum.request({method: 'wallet_switchEthereumChain', params: [{"chainId": "1"}]})` in console to change the network to mainnet for this dapp 6. In Tab 1, click the Send Transaction button, but ignore the confirmation notification (leave it open) 7. In Tab 2, run `await window.ethereum.request({method: 'eth_requestAccounts'})` 8. The confirmation notification window should be focused and visible now, but still be displaying the pending transaction from before ## **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/MetaMask/metamask-extension/assets/918701/48693083-fe60-402f-8798-c32b5db541b6 ## **Pre-merge author checklist** - [x] 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). - [x] I've completed the PR template to the best of my ability - [ ] I’ve included tests if applicable - [x] I’ve documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] 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.
…onfirmation popup focus in request queue (#25497) <!-- 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** <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> [![Open in GitHub Codespaces](https://github.com/codespaces/badge.svg)](https://codespaces.new/MetaMask/metamask-extension/pull/25497?quickstart=1) ## **Related issues** See: MetaMask/core#4457 See: #25397 ## **Manual testing steps** 1. Ensure request queue is toggled on 2. In Tab 1, Visit the test dapp 3. run `await window.ethereum.request({method: 'wallet_switchEthereumChain', params: [{"chainId": "0xaa36a7"}]})` in console to change the network to sepolia for this dapp 4. In Tab 2, Visit a different dapp 5. run `await window.ethereum.request({method: 'wallet_switchEthereumChain', params: [{"chainId": "1"}]})` in console to change the network to mainnet for this dapp 6. In Tab 1, click the Send Transaction button, but ignore the confirmation notification (leave it open) 7. In Tab 2, run `await window.ethereum.request({method: 'eth_requestAccounts'})` 8. The confirmation notification window should be focused and visible now, but still be displaying the pending transaction from before ## **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/MetaMask/metamask-extension/assets/918701/48693083-fe60-402f-8798-c32b5db541b6 ## **Pre-merge author checklist** - [x] 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). - [x] I've completed the PR template to the best of my ability - [ ] I’ve included tests if applicable - [x] I’ve documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] 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.
Should be fixed by #25514 |
Collaborative Effort Required for Root Cause Analysis (RCA) on Critical Issues We are quickly approaching the end of the quarter and we encourage you once again to take some moments and perform RCA on this critical issue. You may do so by answering the questions below: 1. What PR fixed the issue? Please provide your answers as a reply to this comment and tag me as well. You can read more about the initiative here. Thank you! Tagging eng. who added the fix: @jiexi |
Describe the bug
When a user has an unapproved transaction pending, initiating a connect request does not trigger the expected popup to appear.
After the first request is rejected and the subsequent request can be accessed MM can break with an error.
Related issues:
#25393
#25361
Slack discussion links:
https://consensys.slack.com/archives/C03ETQA9EPK/p1695933147044299
https://consensys.slack.com/archives/C03ETQA9EPK/p1695932531166009
Expected behavior
All necessary popups are displayed appropriately.
Screenshots/Recordings
Screen.Recording.2024-06-17.at.10.36.41.AM.mov
Steps to reproduce
Error messages or log output
No response
Version
12.0.0
Build type
None
Browser
Chrome
Operating system
MacOS
Hardware wallet
No response
Additional context
No response
Severity
No response
The text was updated successfully, but these errors were encountered: