Custom Tabs not handling app links correctly
Categories
(Fenix :: App Links, defect)
Tracking
(firefox136 fixed)
Tracking | Status | |
---|---|---|
firefox136 | --- | fixed |
People
(Reporter: quinny898, Assigned: royang)
References
Details
(Whiteboard: [fxdroid][group3])
Attachments
(2 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
Steps to reproduce:
This issue seems to be similar to https://bugzilla.mozilla.org/show_bug.cgi?id=1809264 and may be a regression.
- Open an OAuth authentication flow with Firefox using Custom Tabs
- Successfully finish login, ready to be redirected back
I've tested this on the app I'm reporting for, the Co-op Membership app (https://play.google.com/store/apps/details?id=uk.co.coop.app), as well as the Dominos app (https://play.google.com/store/apps/details?id=uk.co.dominos.android), both using the latest Firefox Nightly as a Custom Tab provider.
Actual results:
- Firefox prompts whether the user wants to re-open the app which requested the authentication. Selecting open works as expected.
- If the user selects cancel or dismisses the prompt without selecting an option, the sign in page remains (this is expected if the dialog is correctly showing)
- Attempting to redirect a second time, either by selecting a link (if provided) or by closing & re-opening login results in the 302 moved page remaining without even asking to redirect.
- The user has to wait 60 minutes (APP_LINKS_DO_NOT_OPEN_CACHE_INTERVAL) or force stop Firefox to see the prompt again.
Expected results:
- The redirect should happen without even prompting the user, or at the very least the prompt should happen again the next time sign in is attempted. Without using Custom Tabs, the correct behaviour is observed.
Reporter | ||
Comment 1•1 month ago
|
||
I was also able to do some poking to work out what I think the cause of this is. It appears that as part of the App Links Interceptor, Firefox checks for tab sessions to check for an authentication flow for, but doesn't check custom tabs. I was able to use a debugger to dump the session state in AppLinksInterceptor.onLoadRequest, which shows that the tabs list is empty but the custom tabs list is populated, as would be expected when using Custom Tabs. Since the interceptor only checks the tab list (using the BrowserState.findTab extension), the custom tab is never found and therefore that the Custom Tab is part of an authentication flow is never recognised.
Assignee | ||
Comment 2•1 month ago
|
||
Great analysis. I'll take a look. Thanks for reporting this.
Assignee | ||
Updated•1 month ago
|
Assignee | ||
Comment 3•1 month ago
|
||
Assignee | ||
Updated•1 month ago
|
Updated•1 month ago
|
Comment 6•27 days ago
|
||
hello co-op friends!
so my esteemed colleague has put in a fix which will stop users from getting completely stuck.
however... it's not as seamless as it could be, you still get the firefox redirect dialog showing.
we looked into this and think it is happening because: on a successful authentication, when you redirect back to the app with an Intent, there are two activities listening for that in your android manifest. We can't see your code but we think this because we get an intent chooser dialog. So you might want to look at that: If there is only one option provided in your manifest to redirect back to, users won't see this confusing dialog, and also firefox will recognise it as an auth flow and won't pop up a message to ask "Would you like to leave Firefox to view this content?". Then the experience will be perfect 😁
happy to chat more if you have any questions about this x
Comment 7•27 days ago
|
||
here is the intent chooser i was seeing on my device fyi
Reporter | ||
Comment 8•27 days ago
|
||
Hi Polly, thanks for the update. We've already fixed that specific issue in an update, it's just not rolled out fully yet - thanks for the heads up though. It was actually when investigating that issue that our test team discovered the issue that led to creating this bug report.
Thanks again all for the super quick action taken on this :)
Reporter | ||
Comment 9•26 days ago
|
||
Confirmed working on the latest Firefox Nightly, thanks again for the super-quick fix
Comment 10•25 days ago
|
||
nice one! great to know - thanks for the info :D
Description
•