wevm / wagmi

React Hooks for Ethereum

Home Page:https://wagmi.sh

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Unable to disconnect and establish a new connection using an injected wallet.

richtera opened this issue · comments

Describe the bug

The fix for When refreshing a page using wagmi some of the connections are not re-established #3710 still has the condition the wrong way and now prevents disconnect and reconnect with a new address.
i.e. it will now permanently see the previous connection, because it's not looking at the isReconnecting flag the correct way.
During a disconnect or a shimmed disconnect, the system should not attempt a "reconnect"

Link to Minimal Reproducible Example

No response

Steps To Reproduce

  • Upgrade to latest run the vite-core example
  • Connect to a wallet, works good.
  • Refresh and stay connected, works good.
  • Disconnect, works good.
  • Connect to a wallet, does not prompt for an address.

Wagmi Version

4.1.22-7-g1167bff5

Viem Version

2.0.0

TypeScript Version

5.4.2

Check existing issues

Anything else?

You may want to look at #3165 again.

@jxom FYI, I think the fix is not ideal.

Basically it doesn't work with wallets that use shimmed disconnect, because the wallet internally will still return the previous address when connecting using eth_accounts.

commented

Will take a look

commented

What wallet are you using? Most wallets that don't support programmatic disconnect do not prompt for acount selection upon eth_requestAccounts if an account is already active (I think they should). MetaMask achieves this via wallet_requestPermissions which works for me. What wallet are you using that prompts upon eth_requestAccounts, so I can test?

Yes our wallet doesn't allow real disconnect because it's up to the user. Therefore we're using the shimmed disconnect. But the code to support the shimmed connect is reversed and says !isReconnecting. The new addition of eth_accounts() is good but is already in that isReconnecting section.
The wallet is the Universal Profiles extension from LUKSO but the code in question will affect all injected wallets. In fact according to the comments in the code the metamask specific connector seems deprecated; otherwise I was going to just implement something more specific.

commented

the shimmed connect is reversed and says !isReconnecting

Correct. We don't want to show a prompt (eth_requestPermissions) upon autoconnect (reconnection). It's typically convention that a user should perform an interaction first (and not see the prompt upon page load).

The wallet is the Universal Profiles extension from LUKSO but the code in question will affect all injected wallets.

Right. I will test out the Universal Profiles extension. It does affect a lot of injected wallets, but that's because those wallets don't deterministically prompt upon every eth_requestAccounts/wallet_requestPermissions request as I mentioned before.

commented

Any tips to connect UP to a localhost dapp? I tried to connect to localhost:5173 initially, but then fell into an infinite loop via the extension, and now extension seems to be propagating 429 errors:

CleanShot 2024-04-03 at 09 06 59@2x

That's correct but only if you reverse the condition. Currently the code that was calling eth_accounts() was in a section of code that said !isReconnecting making it be called at the wrong time. If you change the condition then it would do which I think it should and what you just stated

commented

After rereading this, maybe we are getting the concept of "reconnect" in Wagmi mixed up. The isReconnecting flag is only truthy on page load, when rehydrating connections (perhaps the flag should be called isRehydrating for a better term). It doesn't mean reconnecting from a previously shimmed disconnection.

commented

Anyway, I have a PR here to adjust for the case where a wallet can show account selection prompt upon eth_requestAccounts: https://github.com/wevm/wagmi/pull/3782/files. So it doesn't get skipped anymore.

commented

Should be fixed via b907d5a now.

Maybe although the comment in the code says it should only happen on reconnect. It feels like all the code looks exactly correct but for the opposite case :)

Nice, yes! That totally makes sense to exclude the eth_requestAccount from the reconnecting state!

commented

Should be in wagmi@2.5.18. Thanks for raising!

This issue has been locked since it has been closed for more than 14 days.

If you found a concrete bug or regression related to it, please open a new bug report with a reproduction against the latest wagmi version. If you have any other comments you can create a new discussion.