Bug: MetaMask Chrome extension fails to connect to bridge UI #120

Closed
opened 2026-04-28 13:52:24 +00:00 by PlasticDigits · 2 comments
PlasticDigits commented 2026-04-28 13:52:24 +00:00 (Migrated from gitlab.com)

Summary

User report: MetaMask (browser extension) on Google Chrome does not connect to the bridge web app. Details from the reporter (environment, URL, error text, screenshots) were not attached to this ticket yet—please add them in a comment.

Request for @Brouie

Please try to reproduce this on Chrome + MetaMask extension against the environment the user meant (production https://bridge.cl8y.com/ unless stated otherwise).

  • If you cannot reproduce after following the test matrix below, close this issue with a short comment (Chrome version, MetaMask version, chain selected, and what worked).
  • If you can reproduce, leave the issue open, add confirmed, and paste exact steps, console errors, and any screen recording if helpful.

How to test (matrix)

  1. Browser

    • Latest stable Google Chrome (note version in comment, e.g. chrome://version).
    • Prefer a clean profile or incognito with only MetaMask enabled (disables conflicting wallet extensions).
  2. MetaMask

    • Current extension version (MetaMask → Settings → About).
    • Wallet unlocked before clicking Connect.
  3. Site

    • Production: https://bridge.cl8y.com/
    • If the report is for staging/preview, use that exact origin instead.
  4. Flow

    • Hard refresh (Ctrl+Shift+R).
    • Open Connect / EVM wallet UI and choose MetaMask (not WalletConnect unless the report says otherwise).
    • Confirm whether the MetaMask popup appears, whether approval succeeds, and whether the UI shows a connected address.
  5. DevTools

    • Open Console and Network (filter XHR/fetch).
    • Retry connect once; note any red errors (especially ethereum, CSP, CORS, or blocked popups).
  6. Extensions / OS

    • Note other EVM wallet extensions (Rabby, Coinbase, etc.)—try with them disabled.
    • Corporate VPN / DNS / ad blockers that might block WalletConnect or RPC (less common for pure injected MetaMask, still worth noting).

Possible causes (hypotheses—not confirmed)

  • Multiple injected providers: App uses wagmi with EIP-6963 / multiInjectedProviderDiscovery; another extension could steal focus or confuse discovery (see useEvmWalletDiscovery and EvmWalletModal).
  • Popup / focus: Chrome blocking extension popups or the connect prompt opening behind the window.
  • Wrong or unsupported chain in MetaMask vs. bridge expectations (BSC / opBNB / etc.); user sees a failed switch or silent error.
  • WalletConnect-only mental model: User selects WalletConnect path while expecting extension; or missing / invalid VITE_WC_PROJECT_ID on a given deploy (WalletConnect path broken; MetaMask extension should still work per .env.example—worth verifying which deploy they hit).
  • MetaMask security / Blockaid: “Deceptive request” or similar can block or discourage connection; see docs/METAMASK_BLOCKAID_EVM.md and deployment guide notes on WalletConnect domain verification.
  • Stale site tab: Very old cached bundle; hard refresh or try another machine.
  • In-app browser: If the user is actually inside MetaMask mobile browser or another WebView, behavior differs from desktop Chrome + extension (see detectInAppBrowser.ts).

Information we still need from the reporter

Please ask the reporter (or add if known):

  • Exact URL and time (UTC) of the attempt.
  • Chrome and MetaMask versions.
  • Screenshot or exact wording of any error (UI + MetaMask + browser console if possible).
  • Whether other wallet extensions are installed.
  • Whether they use VPN or strict corporate network.
## Summary User report: **MetaMask (browser extension) on Google Chrome does not connect** to the bridge web app. Details from the reporter (environment, URL, error text, screenshots) were not attached to this ticket yet—please add them in a comment. ## Request for @Brouie Please **try to reproduce** this on Chrome + MetaMask extension against the environment the user meant (production `https://bridge.cl8y.com/` unless stated otherwise). - If you **cannot reproduce** after following the test matrix below, **close this issue** with a short comment (Chrome version, MetaMask version, chain selected, and what worked). - If you **can reproduce**, leave the issue open, add **confirmed**, and paste exact steps, console errors, and any screen recording if helpful. ## How to test (matrix) 1. **Browser** - Latest stable **Google Chrome** (note version in comment, e.g. `chrome://version`). - Prefer a **clean profile** or incognito with **only MetaMask** enabled (disables conflicting wallet extensions). 2. **MetaMask** - Current extension version (`MetaMask → Settings → About`). - Wallet **unlocked** before clicking Connect. 3. **Site** - Production: `https://bridge.cl8y.com/` - If the report is for staging/preview, use that exact origin instead. 4. **Flow** - Hard refresh (Ctrl+Shift+R). - Open Connect / EVM wallet UI and choose **MetaMask** (not WalletConnect unless the report says otherwise). - Confirm whether the MetaMask popup appears, whether approval succeeds, and whether the UI shows a connected address. 5. **DevTools** - Open **Console** and **Network** (filter XHR/fetch). - Retry connect once; note any red errors (especially `ethereum`, CSP, CORS, or blocked popups). 6. **Extensions / OS** - Note other **EVM wallet extensions** (Rabby, Coinbase, etc.)—try with them disabled. - Corporate VPN / DNS / ad blockers that might block WalletConnect or RPC (less common for pure injected MetaMask, still worth noting). ## Possible causes (hypotheses—not confirmed) - **Multiple injected providers**: App uses wagmi with EIP-6963 / `multiInjectedProviderDiscovery`; another extension could steal focus or confuse discovery (see `useEvmWalletDiscovery` and `EvmWalletModal`). - **Popup / focus**: Chrome blocking extension popups or the connect prompt opening behind the window. - **Wrong or unsupported chain** in MetaMask vs. bridge expectations (BSC / opBNB / etc.); user sees a failed switch or silent error. - **WalletConnect-only mental model**: User selects WalletConnect path while expecting extension; or **missing / invalid `VITE_WC_PROJECT_ID`** on a given deploy (WalletConnect path broken; MetaMask extension should still work per `.env.example`—worth verifying which deploy they hit). - **MetaMask security / Blockaid**: “Deceptive request” or similar can block or discourage connection; see [docs/METAMASK_BLOCKAID_EVM.md](docs/METAMASK_BLOCKAID_EVM.md) and deployment guide notes on WalletConnect domain verification. - **Stale site tab**: Very old cached bundle; hard refresh or try another machine. - **In-app browser**: If the user is actually inside MetaMask mobile browser or another WebView, behavior differs from desktop Chrome + extension (see `detectInAppBrowser.ts`). ## Information we still need from the reporter Please ask the reporter (or add if known): - Exact **URL** and **time (UTC)** of the attempt. - **Chrome** and **MetaMask** versions. - **Screenshot** or exact **wording** of any error (UI + MetaMask + browser console if possible). - Whether **other wallet extensions** are installed. - Whether they use **VPN** or strict corporate network.
PlasticDigits commented 2026-04-28 13:52:25 +00:00 (Migrated from gitlab.com)

assigned to @Brouie

assigned to @Brouie
Brouie commented 2026-04-29 00:42:36 +00:00 (Migrated from gitlab.com)

Cannot reproduce on stock setup. Closing per matrix instructions.

Environment

  • Chrome: 147.0.7727.102 (Official Build) 64-bit, Windows 11 25H2 (Build 26200.8246)
  • MetaMask extension: 13.27.0
  • Site: https://bridge.cl8y.com/ (production)
  • Profile: standard (NOT clean profile / not incognito) — kept all my normal extensions enabled to maximize the chance of repro since the issue body specifically calls out multi-provider injection as a hypothesis

Other EVM-injecting extensions enabled at test time

This is a worst-case-style provider collision setup — 7 extensions all touching window.ethereum:

  • Backpack
  • Coinbase Wallet
  • Leap Wallet
  • MetaMask
  • OKX Wallet
  • Phantom
  • Rabby Wallet

Plus several Cosmos/Terra wallets which don't fight over window.ethereum: Cosmostation, Keplr, Station.

Result

MetaMask connected successfully:

  • Bridge UI shows EVM connected: 0xc46b...a80650 with 0.0131 BNB balance
  • Terra/Keplr also auto-reconnected: terra1...vx0wnt with 23,613.85 LUNC
  • Recent Transfers history loaded (4 prior bridge txs from 4/21-4/24)
  • BRIDGE FROM TERRA panel renders complete with fee + ETA
  • Network tab clean: bsc.publicnode.com fetches all 200, no CSP/CORS/blocked-popup errors

Console errors observed (NOT bridge-blocking on this machine, but flagging for dev)

The injected-provider collision IS observable in console even though it didn't break connection here:

  • Uncaught TypeError: Cannot redefine property: ethereum (evmAsk.js:15) — this is OKX's injected provider losing the race
  • Uncaught TypeError: Cannot set property ethereum of #<Window> which has only a getter (requestProvider.js — Coinbase Wallet's likely culprit based on the line range)
  • MetaMask encountered an error setting the global Ethereum provider - this is likely due to another Ethereum wallet extension also setting the global Ethereum provider
  • Backpack couldn't override window.ethereum (injected.js)

So per EIP-6963 / multiInjectedProviderDiscovery, MetaMask still won the race here and wagmi found it. But the race is real and order-dependent. On a machine where extensions load in a different order, OR where another extension wins the race definitively (e.g. Phantom or Rabby asserting earlier), MetaMask might not be discovered at all.

Recommendation for follow-up with the original reporter

Ask the reporter to:

  1. Open chrome://extensions/ and list their EVM-injecting wallet extensions (the same list pattern as above)
  2. Try a clean profile or incognito with ONLY MetaMask enabled — if that works, the multi-provider race is the root cause for them
  3. If they have ONLY MetaMask but still can't connect, that's a different issue (likely Blockaid / network / corporate proxy / cached bundle) and we'd want their console + network errors

Closing as cannot-reproduce on stock + worst-case-collision setup. Reopen if reporter provides specifics that change the picture.

cc @PlasticDigits

Cannot reproduce on stock setup. Closing per matrix instructions. ## Environment - Chrome: 147.0.7727.102 (Official Build) 64-bit, Windows 11 25H2 (Build 26200.8246) - MetaMask extension: 13.27.0 - Site: https://bridge.cl8y.com/ (production) - Profile: standard (NOT clean profile / not incognito) — kept all my normal extensions enabled to maximize the chance of repro since the issue body specifically calls out multi-provider injection as a hypothesis ## Other EVM-injecting extensions enabled at test time This is a worst-case-style provider collision setup — 7 extensions all touching window.ethereum: - Backpack - Coinbase Wallet - Leap Wallet - MetaMask - OKX Wallet - Phantom - Rabby Wallet Plus several Cosmos/Terra wallets which don't fight over window.ethereum: Cosmostation, Keplr, Station. ## Result MetaMask connected successfully: - Bridge UI shows EVM connected: 0xc46b...a80650 with 0.0131 BNB balance - Terra/Keplr also auto-reconnected: terra1...vx0wnt with 23,613.85 LUNC - Recent Transfers history loaded (4 prior bridge txs from 4/21-4/24) - BRIDGE FROM TERRA panel renders complete with fee + ETA - Network tab clean: bsc.publicnode.com fetches all 200, no CSP/CORS/blocked-popup errors ## Console errors observed (NOT bridge-blocking on this machine, but flagging for dev) The injected-provider collision IS observable in console even though it didn't break connection here: - `Uncaught TypeError: Cannot redefine property: ethereum` (evmAsk.js:15) — this is OKX's injected provider losing the race - `Uncaught TypeError: Cannot set property ethereum of #<Window> which has only a getter` (requestProvider.js — Coinbase Wallet's likely culprit based on the line range) - `MetaMask encountered an error setting the global Ethereum provider - this is likely due to another Ethereum wallet extension also setting the global Ethereum provider` - `Backpack couldn't override window.ethereum` (injected.js) So per EIP-6963 / multiInjectedProviderDiscovery, MetaMask still won the race here and wagmi found it. But the race is real and order-dependent. On a machine where extensions load in a different order, OR where another extension wins the race definitively (e.g. Phantom or Rabby asserting earlier), MetaMask might not be discovered at all. ## Recommendation for follow-up with the original reporter Ask the reporter to: 1. Open chrome://extensions/ and list their EVM-injecting wallet extensions (the same list pattern as above) 2. Try a clean profile or incognito with ONLY MetaMask enabled — if that works, the multi-provider race is the root cause for them 3. If they have ONLY MetaMask but still can't connect, that's a different issue (likely Blockaid / network / corporate proxy / cached bundle) and we'd want their console + network errors Closing as cannot-reproduce on stock + worst-case-collision setup. Reopen if reporter provides specifics that change the picture. cc @PlasticDigits
Brouie (Migrated from gitlab.com) closed this issue 2026-04-29 00:42:57 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
code/cl8y-bridge-monorepo#120
No description provided.