Cannot switch chain to mainnet when connect with Metamask App (QR)

[teodorus-nathaniel]

Versions Used

• Thirdweb 5.72.0 - 5.79.0
• Metamask (IOS) v7.37.0 (1512)

How to reproduce:

• Connect metamask with QR (or wallet connect QR but with metamask mobile app)
• Put other chain data to chain parameter in WalletConnectModal. If the chain is undefined, then don't put "locked chains" (the locked chains list below) in the first element of chains
• Switch your metamask wallet connected chain to any chain other than the "locked chains"
• Call wallet.switchChain(...) to "locked chains".
• It will cause error May not specify default Metamask chain.
  

Locked Chains List

• Eth Mainnet
• Eth Sepolia
• Linea
• Linea Sepolia
  

Issue Detail

In thirdweb if the chain is not included in approved list, then the flow is:

1. Call wallet_addEthereumChain
2. Call wallet_switchEthereumChain

In this case, metamask will throw error if you try to call wallet_addEthereumChain with arg of either one of the locked chains.

Another Related Issue

As thirdweb uses @walletconnect/ethereum-provider under the hood to create the provider, I tested that library and check which chains will be included in approved list.
This library will only include the below ids as approved:

1. provided chainId from chain props
2. the current connected chain that user have in their metamask

This makes an issue where if the app is multichain, for example Sepolia and Ozean, and the app wants the user to connect to Ozean first, then we need to put Ozean as the chain props.
Which in turn will make Sepolia not included in approved list, and thirdweb will call wallet_addEthereumChain when switch chain, and throw the error.

Possible Solution

From this comment from metamask's issue
We can apply this kind of behavior in the switchChainWc call

Minimal Reproducible Example

https://github.com/teodorus-nathaniel/thirdweb-bug-reproduce

[linear]

TOOL-2794 Cannot switch chain to mainnet when connect with Metamask App (QR)

[github-actions]

This issue has been inactive for 30 days. It is now marked as stale and will be closed in 5 days if no further activity occurs.