Currently if you conenct using an INJECTED provider like MetaMask, the chainId passed to the connection.connect(type, chainId) method is stored in localStorage. The chainId used there is the app's chainId (the chainId the dapp is expecting the user to use). If the app chain is changed, this will be impacted when using the connection.connect(...) method again, but when using the tryPreviousConnection method, the app chainId is ignored, and the one from localStorage is used. This chainId is different to the one the dapp is expecting the user to use, but the connection still succeeds since the INJECTED type doesn't use the chainId parameter at all. The problem is that after that successful connection, the chainId that is left in localStorage is wrong, and it will stay like that until a new connection.connect(...) is called with the right data.
This PR fixes the issue by updating the chainId in localStorage after a successful tryPreviousConnection, and also return the current chainId in the ConnectionResponse. This is only done for INJECTED provider types since those are the only ones that don't fail on a wrong chainId.
Currently if you conenct using an
INJECTEDprovider like MetaMask, the chainId passed to theconnection.connect(type, chainId)method is stored in localStorage. ThechainIdused there is the app's chainId (the chainId the dapp is expecting the user to use). If the app chain is changed, this will be impacted when using theconnection.connect(...)method again, but when using thetryPreviousConnectionmethod, the app chainId is ignored, and the one from localStorage is used. This chainId is different to the one the dapp is expecting the user to use, but the connection still succeeds since theINJECTEDtype doesn't use thechainIdparameter at all. The problem is that after that successful connection, thechainIdthat is left in localStorage is wrong, and it will stay like that until a newconnection.connect(...)is called with the right data.This PR fixes the issue by updating the
chainIdin localStorage after a successfultryPreviousConnection, and also return the current chainId in theConnectionResponse. This is only done forINJECTEDprovider types since those are the only ones that don't fail on a wrongchainId.