[Bug]: Multichain - When a user has an unapproved tx and tries to connect to another site, after accepting/rejecting the tx, the popup connect screen is opened and closed automatically without any action #25407
Labels
regression-RC-12.0.0
release-12.0.0
Issue or pull request that will be included in release 12.0.0
release-12.1.0
Issue or pull request that will be included in release 12.1.0
Sev2-normal
Normal severity; minor loss of service or inconvenience.
team-wallet-api-platform
type-bug
Comments
seaona
added
type-bug
Sev2-normal
|
I can verify this is happening -- after rejecting the Swap transaction, I can see the "Sign in" contents just briefly before the popup closes itself. |
|
This should be resolved by #25310 |
7 tasks
metamaskbot
added
the
release-12.1.0
jiexi
added a commit
that referenced
this issue
Jun 20, 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 `^1.0.0` in order to handle the case where `eth_requestAccounts` requests that would not cause a confirmation to be presented to the user (because they have permitted some accounts for that dapp) would be stuck behind the request queue when they could just be passed through. [](https://codespaces.new/MetaMask/metamask-extension/pull/25310?quickstart=1) See: MetaMask/core#4423 Fixes: #25407 1. Open https://metamask.github.io/test-dapp/ and https://app.odos.xyz/, connect to both 1. On the Test Dapp, send an EIP 1559 txn, but do not confirm/reject the confirmation nor close the popup 1. Reload ODOS 1. ODOS should show that is connected to MetaMask in the top right of the webpage 1. Open console on the ODOS page 1. run `await window.ethereum.request({method: 'eth_requestAccounts'})`, it should return immediately with the permitted accounts <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> https://github.com/MetaMask/metamask-extension/assets/918701/b76607ef-b0a3-4943-b1d5-85f8cd766343 - [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. - [ ] 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 <[email protected]>
jiexi
added a commit
that referenced
this issue
Jun 20, 2024
…#25451) cherrypicks ba8d84e which bumps `queued-request-controller` to `^1.0.0` and fixes the `eth_requestAccounts` handling bug Merge conflicts on the lavamoat policies Fixes: #25407 --------- Co-authored-by: MetaMask Bot <[email protected]>
|
this should be fixed in the V12 branch now |
metamaskbot
added
the
release-12.0.0
|
Missing release label release-12.0.0 on issue. Adding release label release-12.0.0 on issue, as issue is linked to PR #25310 which has this release label. |
|
Verified fixed in #25098 (comment) |
](https://codespaces.new/MetaMask/metamask-extension/pull/25310?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
Whenever I have an unapproved transaction, if I go to another dapp and click Connect, once I accept/reject the pending transaction, I see how the popup is opened with the Connect screen and right after, is automatically closed without giving a chance to connect.
The wallet remains not connected after that.
Expected behavior
We should not close the popup and let the user proceed in the connect screen
Screenshots/Recordings
connect-disappears-pending-tx.mp4
Steps to reproduce
Error messages or log output
No response
Version
12.0.0
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: