Connection Issues in ANdroid

Embedded Wallets (Web3Auth)
,
2

Hi Natalia — thanks for the clear report and code sample. I hear you: desktop works but Android fails (and iPhone is extremely slow). I pulled the key details and wrote a concise summary for the support team, plus likely causes and targeted next steps you can try. If you prefer, I can open the ticket with this exact info.

Summary (extracted from your message)

  • SDK / integration: MetaMask Embedded Wallets (using Web3Auth)
  • Packages & versions provided: @web3auth/modal “^10.5.4”, @web3auth/ethereum-provider “^9.7.0”
  • Platform(s) affected: Android (Chrome on Android 10 — popup never shows; timeout on web3Auth.init). iPhone: connection works but very slow.
  • App framework: Vue 2
  • Behavior: web3AuthInit() times out on Android (your custom 15s timeout). Some attempts return LoginError code 5113 “login popup has been closed by the user” even though popup never appears. Worked before upgrading to v10; you moved initialization to only when user chooses Web3Auth and added a timeout to wait until ready.
  • Code snippets attached: web3AuthInit() and SESSION_CONNECT_WEB3AUTH action (connectTo usage). Good: you included init/connect flow and error logs.

Most relevant hypotheses / root causes

  1. Popup-blocking / user-gesture: Browsers (especially mobile) often block popups if the popup is not opened synchronously inside a user-initiated event. From your description you initialize and then await readiness (using a timeout) before calling connectTo — that breaks the “same user gesture” requirement and commonly causes the error that the popup was closed or never opened. Desktop is more permissive; mobile Chrome / WebView is stricter.

  2. In-app WebView vs full browser: If the page is running inside an embedded WebView (e.g., inside an Android app, Facebook in-app browser, or some custom WebView), the Web3Auth modal/popups might not open or behave correctly. The UA/Chrome version in your logs (141.0.0.0) suggests it might be a WebView-like environment.

  3. Cross-origin / cookie / secure context issues: Mobile browsers with strict third-party cookie or cross-origin policies can interfere with popup-based OAuth flows. Also make sure the site is served over HTTPS and the origin matches the clientId settings in Web3Auth dashboard.

  4. Version / API usage: v10 changed some behaviors. Ensure you’re using the recommended modal/provider APIs for mobile. Consider upgrading to latest patch versions — sometimes fixes for mobile popup/redirect handling are included.

Actionable recommendations (quick, prioritized)

  1. Ensure connectTo (login popup) runs synchronously inside the user’s click handler. Don’t await long initialization after the click. Option A: initialize Web3Auth on page load (init only) so connectTo can run directly on click. Option B: start the connect/openLogin directly inside the click (no intervening asynchronous waits that break the gesture).

    • Example approach: create the Web3Auth instance eagerly (new Web3Auth(…); await init() on page load) but only call connectTo when the user clicks. That avoids popup blocking while not showing the modal until asked.

  2. If you must initialize at click time and init() is async, use a redirect login flow for mobile (if Web3Auth supports it) rather than a popup, or show an in-page loading state and open the popup from a user-gesture-friendly API right away.

  3. Confirm you are running in a full Chrome browser and not a restricted WebView. If it is a WebView, try testing in Chrome browser on the same device to compare. If you need to run inside WebView, check Web3Auth docs for supported mobile flows or consider deep-link / universal-link configuration.

  4. Check origins/redirect URIs / clientId settings in your Web3Auth dashboard and ensure HTTPS and origin are correct for mobile. Also test with third-party cookies enabled (or check Web3Auth mobile recommendations).

  5. Try upgrading @web3auth/modal and @web3auth/ethereum-provider to latest patch versions if possible — mobile modal fixes are sometimes shipped in patch releases.

  6. Increase diagnostic logging: capture browser console logs and network logs during the mobile attempt. This will help find if requests are blocked or if errors happen before popup creation.

What I still need from you (only if you can share — I don’t want to spam you):

  • Are you running inside an embedded WebView (a mobile app) or in Chrome/Edge/Samsung Internet as a normal tab? (This is important.)
  • A short copy of the browser console logs from Android (especially around the init/connect calls) or a screenshot of the console/network timeline. You already shared the timeout and 5113 error which is helpful.
  • Confirm origin/protocol (is the page served via HTTPS in production?).

Useful references

  • MetaMask docs (general integration info): https://docs.metamask.io
  • Web3Auth best-practices for mobile/login flows — check your Web3Auth modal docs and mobile/redirect guidance in the Web3Auth docs (they cover popup vs redirect and WebView support).

If you want, I can:

  • Suggest a small code change to ensure connectTo is called synchronously on click (I can show a minimal pattern), or
  • Draft a support ticket for you including the summary above and the logs you already pasted.

Which would you prefer? If you want a code example to run connectTo on user click without losing the user-gesture, tell me whether you can initialize Web3Auth on page load (yes/no) and I’ll return a tiny code pattern tuned for Vue2.

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