Frontend: fix bugs in Bitkeep mobile wallet #1559
Conversation
…rsion to a request This is a monkeypatch to the function. It is necessary because Bitkeep uses a buggy version of the window.ethereum API. Only some rpcs like the ones of optimism require the version field.
Checks the chainId of the provider and copies its value after a chain switch triggered by the dapp. Also moves the network switch listening to our EthereumProvider, because I think this logic has no relation to the RequestDialog where it was before. Also now uses the network event of ethers.js. This was more reliable than the one of the window.ethereum API.
manuelwedler
changed the title
There was a problem hiding this comment.
Everything looks good. Thanks for all the effort around this issue.
I just have one question and one concern outside of the scope of this issue.
I tried testing the app with multiple wallet providers (TrustWallet, BitKeep, TokenPocket) by opening app.beamerbridge.com inside their WebView and it seems like all of them are showing different behaviors. Most noticeable:
- TrustWallet is not showing the right wallet connection options (missing MetaMask option)
- All of them are not emitting any events when network change happens which makes the app unusable / prone to errors when trying to submit a transfer
We can create a follow up issue for investigating this further as i believe this needs some attention.
| this.chainId.value = newNetwork.chainId; | ||
| if (oldNetwork) { | ||
| window.location.reload(); | ||
| } |
There was a problem hiding this comment.
I am trying to figure out why the location.reload() was moved in the ethereum-provider.ts.
Was the intention to substitute the removed watcher from RequestDialog.vue?
There was a problem hiding this comment.
Exactly, it was before in the RequestDialog and I think this logic has no relation to the component. It is only dependent on the provider and that's why I think it should also be placed there.
There was a problem hiding this comment.
Alright, seems reasonable
|
Are you sure they are not emitting any events? I could verify that BitKeep is throwing the event, but the call to |
|
You are right, the event emitting is not the problem here but rather the |
Closes #1513
Ensures that no transfers are shown mistakenly as failing with Bitkeep. During testing I also found that the chain switching does not work properly with Bitkeep. This is also fixed. See commit messages for details.