PoC: Fix external Custom Tab auth callbacks

[jonathanKingston]

Avoid prompting on non-HTTP(s) callback intents when running as an external Custom Tab to prevent OAuth/app-link flows from looping back to the start. Also preserve original Custom Tabs extras when routing into CustomTabActivity and fix incorrect flag bitmasking.

Task/Issue URL: https://app.asana.com/1/137249556945/project/715106103902962/task/1211773313492727?focus=true

Description

Steps to test this PR

Feature 1

• [ ]
• [ ]

UI changes

Before	After
!(Upload before screenshot)	(Upload after screenshot)

---

Note

Avoid prompts for non-HTTP(s) app-link callbacks in external Custom Tabs, preserve original Custom Tabs extras when launching, and fix intent flag composition.

• Custom Tabs behavior
  • For Command.HandleNonHttpAppLink, when in an active external Custom Tab, launch non-HTTP(s) intents directly via launchNonHttpAppLinkFromExternalCustomTab(...) (with fallback intent/URL handling and chooser) instead of prompting.
  • Add BrowserTabFragment.launchNonHttpAppLinkFromExternalCustomTab(...) to handle direct launches and fallbacks.
• Intent preservation
  • Update CustomTabActivity.intent(...) to accept originalIntent and copy Custom Tabs extras (e.g., session) before routing to CustomTabActivity.
• Flag fix
  • In IntentDispatcherActivity.showCustomTab, pass originalIntent = intent and fix flags from bitwise AND to OR: FLAG_ACTIVITY_NEW_TASK | FLAG_ACTIVITY_CLEAR_TASK | FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS.

^{Written by Cursor Bugbot for commit 502ddd2. This will update automatically on new commits. Configure here.}

[cursor]

Bug: Copied intent preserves original flags causing unexpected behavior

When creating the Custom Tab intent, Intent(it) copies all fields from the original intent including its flags, and then addFlags(flags) ORs the new flags with the existing ones. The comment says "preserve Custom Tabs extras" but this approach also preserves the original intent's flags. If the calling app set any conflicting flags (like FLAG_ACTIVITY_SINGLE_TOP, FLAG_ACTIVITY_BROUGHT_TO_FRONT, etc.), they would combine with FLAG_ACTIVITY_NEW_TASK | FLAG_ACTIVITY_CLEAR_TASK | FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS and could cause unexpected activity launch behavior. If only extras need to be preserved, the flags portion should be explicitly set rather than added.

---

_{Please tell me if this was useful or not with a 👍 or 👎.}

 

[cursor]

Bug: Missing deferred URL load for new tab scenario

When loading fallbackUrl in launchNonHttpAppLinkFromExternalCustomTab, the code directly calls webView?.loadUrl(fallbackUrl, headers). The original openExternalDialog function checks viewModel.linkOpenedInNewTab() and uses webView.post to defer the load when true, ensuring the WebView is properly attached. If a new tab is opened within an external Custom Tab (via window.open or target="_blank"), isLinkOpenedInNewTab would be true, but this new function skips the deferred loading pattern. This could cause a race condition where the URL load is attempted before the WebView is ready.

---

_{Please tell me if this was useful or not with a 👍 or 👎.}