Arkie-Library-Frontend/.unipi/docs/fix/2026-06-06-imtoken-production-login-fix.md

title, type, date

title	type	date
imToken production in-app browser login — Quick Fix	quick-fix	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.