Hi Natalia — thanks for the detailed report, appreciate the thorough code and logs. I’ve pulled out the key details for the support team and included a few targeted troubleshooting steps you can try now.
Summary (what you reported)
- Tone: Reporting an issue (unstable connection on mobile after migration).
- SDK: @web3auth/modal (Web3Auth modal integration — Embedded Wallet flow)
- SDK version: upgraded to v10.8 (issue appeared after migrating to v10.5.4; you upgraded to 10.8)
- Platform / framework: Vue 2 (mobile browsers on Android and iPhone — issue most visible on Android mobile data)
- Behavior: Works fine on Wi‑Fi. On mobile data (or poor connectivity) the connect flow frequently fails. Most common logged error is WalletLoginError code 5114: “Wallet popup has been closed by the user.” — but you report the popup often never opens.
- Code: You provided web3AuthInit() (init in separate view) and a Vuex action that calls web3AuthInstance.connectTo(WALLET_CONNECTORS.AUTH, {…}). You wait for status === ‘ready’ with an interval before allowing login.
- Already attempted: avoiding asynchronous initialization and clearing Web3Auth storage on failure.
Likely causes (based on symptoms)
- Popup being blocked because the actual connect() / connectTo() call is not executed as a direct user gesture (click). Browsers treat actions that are performed after async/await or via store actions as non-user initiated and may block popups — that yields a “popup closed” error even if the popup never visibly opened.
- Poor / captive network: mobile data with slow connectivity or a captive portal (carrier login, restricted network) can break the popup load and cause it to close or time out.
- Race between init completion and connect: if init hasn’t finished or instance moved from ready → connecting unexpectedly, the popup flow may fail.
Immediate suggestions to try
- Ensure connectTo is invoked synchronously from the user gesture (the click handler) if possible. Avoid awaiting other async operations before calling connectTo. Example: call web3AuthInstance.connectTo(…) immediately inside the click event handler rather than via an async action that awaits unrelated work first.
- Use a redirect-based/mobile-friendly flow as fallback. On mobile, redirect flows (or deep-link flows) are more reliable than popups when network conditions are spotty. If Web3Auth offers a redirect/loginUsingRedirect option for the adapter you’re using, try that for mobile devices.
- Double-check web3AuthInstance.status === ‘ready’ right before calling connectTo. If not ready, don’t defer large async work — either block the login UI until ready or call connect synchronously when it becomes ready via a direct user interaction.
- Reproduce with remote debugging (Chrome DevTools remote) and capture console + network logs on the mobile device to see failed requests, CORS, or timeouts.
- Try an incognito session / clear storage first and test on mobile data to confirm it isn’t stale-storage related (you already have clearWeb3AuthStorage() — try forcing the clear before init in a test run).
- If available, upgrade to the latest patch of @web3auth/modal (if anything newer than 10.8 exists) or check the library’s changelog for popup/timeout fixes.
What I need from you (to pass to support or to continue troubleshooting)
- Confirm whether the connectTo call is executed directly inside the click handler (synchronous) or always runs through async store actions. If it’s not called synchronously, try making a quick test to call it directly in the click handler.
- Browser console logs (mobile remote debugging) captured during a failed attempt — especially any errors or network failures. Network HAR / screenshot of the DevTools Network tab would be ideal.
- A short screen recording or screenshot showing whether any popup appears or if there’s a visible redirect attempt.
- Confirm whether the problem reproduces in mobile incognito mode (no extensions/cached state) and whether captive portal/login screens are present on the mobile carrier network.
If you want, I can package this into a ticket-friendly summary for the support team (including the code you pasted) — I already have the main pieces, but console HARs/screenshots will speed resolution. Which would you like me to prepare next?
Note: This response was generated by an AI bot and may require further verification. The MetaMask Community Team has tracked this issue and will be responding as soon as possible.
Additionally, we would recommend you to join our biweekly Office Hours to get this resolved even faster. MetaMask Developer Office Hours