Intermittent mobile wallet pairing issue

[IsaccoSordo]

Originally reported by Kukai

Description

On mobile devices, there is an intermittent issue where pairing with the wallet fails. It appears that after a successful pairing, the expected requestPermission is not sent, causing the dApp to become unresponsive.

Steps to Reproduce

1. Initiate wallet pairing on a mobile device.
2. Complete the pairing process.
3. Switch to another app (triggering an app switch).
4. Return to the beacon dApp.
5. Observe that the dApp does not trigger requestPermission and becomes stuck.

Expected Behavior

After pairing, the dApp should automatically call requestPermission to complete the process and allow full functionality.

Actual Behavior

The dApp fails to set the requestPermission, which causes it to get stuck. This issue is likely related to the mobile browser being hibernated during app switching.

Additional Context

• The problem appears sporadically and is more prevalent on mobile devices.
• The issue might be tied to the mobile operating system’s handling of app switching, where the browser running the beacon dApp enters a hibernation state.

Environment

• Mobile devices (specific OS and version details may help in further investigation)

Possible Impact

Users may experience difficulties in using the dApp if they switch apps after pairing with the wallet, leading to a broken workflow.

Suggested Next Steps

• Investigate the app switching behavior on various mobile operating systems.
• Determine if there is a way to re-trigger requestPermission when the dApp resumes from a hibernated state.
• Explore potential workarounds to maintain the active state of the dApp during app switching.

[IsaccoSordo]

This happens due to how mobile OSs manage app switching behavior. When we switch from a dApp using Beacon to a Wallet app, the OS hibernates the app that loses focus. Because of this behavior, if we send a sign request after requesting permission, there is a chance that the sign request either gets lost or is only sent after switching back to the dApp tab. Another problem is that we can only control the switch from the dApp to the Wallet, not vice versa, meaning we rely on the wallet to return to the dApp to resume operations. With WalletConnect, we can mitigate this behavior by listening to RELAYER_EVENTS. When RELAYER_EVENTS.connect is triggered, we know the dApp has resumed connection with the relayer, and based on the wallet's response, we continue communication by sending the next queued request. We are still running internal tests to determine how we can better mitigate this behavior.

[IsaccoSordo]

This is by design. We could also reproduce with Uniswap and MetaMask on ETH.