---
title: "imToken production in-app browser login — Quick Fix"
type: quick-fix
date: 2026-06-06
---

# imToken production in-app browser login — Quick Fix

## Bug

`main` serves `ark-library.com`, while `terry-wallet-login` serves the staging site. imToken login worked on staging, but on `ark-library.com` the imToken deeplink could open the in-app browser without completing login.

## Root Cause

The production imToken in-app browser path depends on injected wallet provider behavior after the deeplink opens `ark-library.com`. Some imToken environments can expose a legacy provider shape (`window.web3.currentProvider`, `selectedAddress`, or `enable()`) or fail BNB-chain switching even though the wallet address is already available. The previous flow required the modern EIP-1193 path and chain switch to succeed, so login could silently fail before the frontend posted the wallet address to the backend.

## Fix

Made the injected wallet login path more tolerant for imToken/mobile in-app browser environments:

- Detect legacy `window.web3.currentProvider` if `window.ethereum` is unavailable.
- Accept `selectedAddress` when it is already exposed by the wallet.
- Fall back to legacy `ethereum.enable()` if `eth_requestAccounts` fails.
- Do not block wallet-address login if BNB-chain switching fails, because the backend login only needs the wallet address.

### Files Modified

- `src/wallet/injected.ts` — adds legacy provider/address fallbacks and makes BNB-chain switching non-blocking for injected wallet login.

## Verification

- `npx prettier --write src/wallet/injected.ts`
- `npx tsc --noEmit`
- `npm run format:check`
- `npm test`
- `VITE_API_URL="" VITE_API_PREFIX="/apnew" VITE_DISABLE_ADMIN="true" npm run build`

## Notes

The production fix was committed and pushed to `main` as `9c4b8a4 fix: support imToken in-app browser login`; Terry confirmed CI handles deploy for `ark-library.com`.