Sending transactions on iOS shows a deep link prompt after first attempt

Describe the bug

Attempting to send a transaction on iOS via @walletconnect/ethereum-provider + ethers shows a prompt to the user to open in the app rather than opening the app automatically after the first attempt.

It seems to be caused by the fact that the deep link navigation is triggered some time after the user interaction has occurred. The browser then intercepts the navigation, giving users a chance to back out of it.

I pushed a minimal repro here: https://github.com/markdalgleish/walletconnnect-deeplink-prompt-issue It’s deployed here: https://walletconnnect-deeplink-prompt-issue.vercel.app

I was also able to reproduce this same issue by simply navigating to the deep link URL after a 1s timeout. To help with debugging, I also included a button for doing this in my minimal repro. Note this doesn’t happen if you navigate immediately, so there’s also a button for this too for comparison.

I’m not sure if this is something that can be fixed or not, short of pre-emptively navigating to the deep link URL, but I realise that might also cause issues with requests that are still in flight. Either way, I figured it was worth raising since it’s not a great user experience.

SDK Version

• Client: JS
• Version: @walletconnect/ethereum-provider@1.7.8

To Reproduce Steps to reproduce the behavior:

1. Go to https://walletconnnect-deeplink-prompt-issue.vercel.app on iOS.
2. Connect wallet.
3. Tap “Send transaction”.
4. Cancel request and go back to browser.
5. Tap “Send transaction” again.
6. See prompt to Open this page in "App name"?

Expected behavior Immediately navigates to the app, the same way it did on the first attempt.

Screenshots

Smartphone:

• Device: iPhone 12 Pro
• OS: iOS 15.5
• Browser: Safari

[jxom]

Update: we are starting to work on “eager” hooks in wagmi (using @markdalgleish’s eager populating of txn request) to help with deeplinking issues on iOS.

https://github.com/tmm/wagmi/pull/658

[markdalgleish]

I’ve been digging into JsonRpcSigner in Ethers to understand this a bit more, and here’s what I’ve found.

Calling signer.sendTransaction(tx) results in two blocks of async work happening before the deep link fires:

• It calls this.provider._getInternalBlockNumber (source)
• It then calls this.sendUncheckedTransaction which itself performs a couple of async calls:
  • If the transaction’s gasLimit property is nullish, it calls this.provider.estimateGas (source)
  • If the transaction’s to property exists, it calls this.provider.resolveName (source)

Knowing this, I’ve been able to work around the timing issues by doing the following:

• Resolve the gasLimit and to properties up front by calling signer.populateTransaction (source) rather than doing it as part of the sendTransaction call.
• Call signer.sendUncheckedTransaction directly so that it doesn’t call this.provider._getInternalBlockNumber.

I’ve expanded my repro to include a demo of this. There’s now an additional row of actions where you can populate a transaction, then—when it’s ready—pass it to either sendTransaction or sendUncheckedTransaction.

I’ve found that tapping “Send transaction” still works most of the time, but occasionally prompts me to open in the app instead of navigating immediately. If I tap “Send unchecked transaction”, it takes me directly to the app every time without a prompt.