Fix WSJ Custom Tab redirect loop#8520
Draft
kzar wants to merge 6 commits into
Draft
Conversation
The Wall Street Journal (WSJ) app sometimes loads articles inside a Chrome Custom Tab (CCT)[1]. When it does, if the user's default browser was set to DuckDuckGo, they could sometimes be trapped in a CCT -> App Link redirection loop, as their phone switched from the DuckDuckGo browser, back to the WSJ, and back again repeatedly. It turns out, that Chromium has some logic[2] to ensure that such navigations are user-initiated before opening the registered app for it. Let's do the same. Notes: - The isUserQuery() check allows navigations that were initiated by the user via the address bar to then be opened in an app. - Non-HTTP App Links are handled via `handleNonHttpAppLink` which isn't changed here. Chromium seems to force a user prompt for non-user-initiated non-HTTP navigations, we could consider doing the same in the future. 1 - https://developer.chrome.com/docs/android/custom-tabs 2 - https://source.chromium.org/chromium/chromium/src/+/09aafe21bc1b6c78e92fa4197d4e3c8401caaee9:components/external_intents/android/java/src/org/chromium/components/external_intents/ExternalNavigationHandler.java;l=1230-1235
kzar
force-pushed
the
kzar/bugfix/cct-app-loop
branch
from
839a1c7 to
fa6117e
Compare
kzar
changed the title
kzar
changed the title
kzar
force-pushed
the
kzar/bugfix/cct-app-loop
branch
from
090ad55 to
e48c5a2
Compare
The previous commit blocked HTTP App Link hand-off when no user gesture was associated with the navigation. That avoids the WSJ <-> Custom Tab redirect loop problem, but it also blocks some legitimate OAuth-style flows, where the opened page does not require user interaction (e.g. where the user was already signed in). Chromium handles this with a "trusted-caller" carve-out[1]. If an app opens a Custom Tab, and then that Custom Tab opens an App Link that points back to that same app, let it through even without user interaction. Let's add similar logic here: - DuckDuckGoCustomTabService.newSession() records (token -> client package) in a new CustomTabsSessionRegistry. cleanUpSession() clears it. - IntentDispatcherViewModel looks up the verified package when handling a CCT intent, and passes it down through CustomTabActivity, BrowserTabFragment, and into BrowserTabViewModel.setIsCustomTab(...). - The gate in BrowserTabViewModel.handleAppLink gains `|| isTrustedCaller`, where isTrustedCaller is true only in CCT mode and only when the registered client package equals the App Link's target package. 1 - https://source.chromium.org/chromium/chromium/src/+/09aafe21bc1b6c78e92fa4197d4e3c8401caaee9:components/external_intents/android/java/src/org/chromium/components/external_intents/ExternalNavigationHandler.java;l=1203-1208
kzar
force-pushed
the
kzar/bugfix/cct-app-loop
branch
from
e48c5a2 to
b7895b6
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Task/Issue URL: https://app.asana.com/1/137249556945/inbox/1200776578788342/item/1211781703927439/story/1214682781164811?focus=true
Description
If the user sets the DuckDuckGo browser as the default, and then taps to open an article link inside the WSJ app, they can get trapped in an endless redirect loop, where the WSJ app opens the DDG browser, which in turn opens the WSJ app again, etc.
Let's fix that by mirroring Chromium's behaviour[1]:
Notes:
CustomTabsIntent.Builder(session)). That is the only thing preventing the redirect loop also happening in Chromium.isUserQuery()check allows navigations that were initiated by the user via the address bar to then be opened in an app.handleNonHttpAppLinkwhich isn't changed here. Chromium seems to force a user prompt for non-user-initiated non-HTTP navigations, we could consider doing the same in the future.Steps to test this PR
Check that the WSJ redirection loop is fixed
Check that OAuth flows still work
1 - https://source.chromium.org/chromium/chromium/src/+/09aafe21bc1b6c78e92fa4197d4e3c8401caaee9:components/external_intents/android/java/src/org/chromium/components/external_intents/ExternalNavigationHandler.java;l=1230-1235