Fix Android Chrome return path breaking same-device completion (#58) - #59
Fix Android Chrome return path breaking same-device completion (#58)#59SuperstrongBE wants to merge 2 commits into
Conversation
…twork#58) On Android Chrome, the hard-coded 'android-app://com.android.chrome' return_path relaunched Chrome on a fresh tab after signing in WebAuth, orphaning the originating tab's pending login/transact promise. - generateReturnUrl(): drop the bare-package Chrome intent and fall through to window.location.href so the return lands on the dApp's own origin (intent schemes kept for Firefox/Edge/Opera/Brave/WebView) - isMobile(): stop relying on window.orientation (removed in modern Chrome for Android); use the UA-based isAndroid()/isAppleHandheld() signals so the same-device trigger and return-path logic agree - BrowserTransportOptions.returnUrl (string or factory): lets apps override return_path with their real URL for their own session-restore Fixes XPRNetwork#58 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FELCBotNWhbd72JvfEB9CN
On Android the wallet's return navigation always lands in a NEW Chrome tab (no URL scheme can focus the originating one from another app), so each same-device sign piled up an extra tab even though the original tab completes the flow. Tag the Android return URL with a '#webauth-return' fragment and, when the transport boots in a tab carrying that marker, call window.close(). Tabs spawned by an external app intent are allowed to close themselves, which drops the user back on the originating tab. If the close is denied the tab simply stays on the dApp origin — no regression. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FELCBotNWhbd72JvfEB9CN
|
Follow-up commit after real-device testing: the flow now completes (the originating tab receives auth / identity proof / payment events), but each same-device sign still opened one extra Chrome tab — on Android the wallet's return navigation always lands in a new tab, since no URL scheme can focus an existing one from another app. New commit tags the Android return URL with a |
|
@SuperstrongBE Is this PR still in Draft because you do some extra testing? |
|
Check the issue, I commented after deep dive |
| // stock Chrome on Android: a bare `android-app://com.android.chrome` intent relaunches | ||
| // Chrome on a new tab instead of returning to the originating one, orphaning the pending | ||
| // request — fall through to the current URL so the flow completes on the dApp's origin | ||
| if (isAndroid()) { |
There was a problem hiding this comment.
@SuperstrongBE Does this cover the case when user works in browser different from Chrome? Firefox for example. Previous check had isChromeMobile
Yes, I saw it. I asked WebAuth team to check. But if I understand correctly your PR still fixes several issues, so it worth merging. That's why I wanted to clarify why it is marked as Draft. |
Got it. I make it ready to review. When webauth team come back, i can iterate to harden the fix if needed. |
|
@andreyjamer waiting for your click on merge:) |
|
@SuperstrongBE Could you check my comment? |
2 participants
Summary
Fixes #58: on Android Chrome, the hard-coded
android-app://com.android.chromereturn_pathrelaunched Chrome on a fresh tab after signing in WebAuth, orphaning the originating tab's pendingConnectWallet()/session.transact()promise — login and same-device signing never completed.Three fixes, all in
@proton/browser-transport:returnUrl— new optionalreturnUrl?: string | (() => string)onBrowserTransportOptions, used for thereturn_pathinfo key in bothonSessionRequestanddisplayRequest. Flows through@proton/web-sdk's existingtransportOptionsspread with no further changes. Non-breaking.generateReturnUrl()no longer emits the bare-package Chrome intent; it falls through towindow.location.href, so the return lands on the dApp's own origin where session-restore can complete. Intent schemes are kept for Firefox/Edge/Opera/Brave/WebView.isMobile()— drops thewindow.orientationdependency (removed in modern Chrome for Android) in favor of the UA-basedisAndroid()/isAppleHandheld()signals, so the same-device trigger and the return-path logic agree on the platform.Testing
pnpm --filter @proton/browser-transport build— OK (cjs, esm, types, bundle)pnpm build— 10/10 turbo tasks OK🤖 Generated with Claude Code
https://claude.ai/code/session_01FELCBotNWhbd72JvfEB9CN