1859052 - intent URLs don't ever seem to fall back to S.browser_fallback_url in Firefox (whether or not you decide to open the external app)

Status: RESOLVED FIXED

(Firefox for Android :: App Links, defect, P3)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Steps to reproduce

1. Load attached testcase in Firefox on Android.
2. Tap the link.
3. If you're prompted to "Open in another app", tap "Cancel".
4. (if you're still looking at the testcase): Try tapping the link again.

Expected behavior

I should end up at the fallback URL.

Actual behavior

No navigation happens at all.

Device information

• Firefox version: Nightly 120.0a1
• Android device model: Pixel 6a
• Android OS version: 14

Any additional information?

• Chrome gives EXPECTED RESULTS
• I ran into this when trying to do a "Safeway Pickup" grocery order, without having the safeway app installed on my phone. In that real-world-case, I had a texted safeway.onelink.me short-URL (where I was supposed to notify the store that I had arrived, to pick up my groceries). That short-URL results in a 301 redirect to a long order-specific intent:// URL, which is crafted to launch the safeway app, and it includes a S.browser_fallback_url with a URL of an equivalent page on the Safeway website. If I load the short URL (or the expanded intent:// URL) in Chrome, it properly falls back to the Safeway website and lets me complete my Safeway pickup. If I load it in Firefox, I'm prompted to open the app (which I don't have installed, so I click "cancel") and then I'm left looking at a blank tab in Firefox. Repeated attempts just take me directly to the non-functional blank tab. This forces me to use another browser in order to complete my grocery pickup.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug in Firefox Nightly vs. working-as-expected in Chrome

Comment 2

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #0)

3. If you're prompted to "Open in another app", tap "Cancel".

Note, if I instead tap "Open" to accept the invitation to open the external app, I'm taken the the Google Play store's page for the app in question (Safeway in this case). If I then go back because I don't want to install the app for whatever reason, there's still no way for me to get Firefox to take me to the fallback URL, as far as I can tell.

royang: I see you've commented on several bugs relating to intent fallback URLs, e.g. bug 1795161 and bug 1840434 -- could you take a look and do you know if/how this is meant to work?

Comment 3

[Roger Yang [:royang]]

:dholbert, I'll take a look. Thanks

Comment 4

[Roger Yang [:royang]]

Attachment: testcase 2.html

Modified to target chrome browser

Comment 5

[BMO Github Automation]

Attachment: [mozilla-mobile/firefox-android] Bug 1859052 - Use fallback URL if user cancelled launching in external app (#5108)

Comment 6

[Daniel Holbert [:dholbert]]

Comment on attachment 9372130 [details]
testcase 2.html

(It looks like testcase 2 is really html rather than plaintext --> updating mimetype in the bugzilla attachment details. If you wanted it as plaintext for some reason, please accept my apologies & feel free to revert this tweak.)

Comment 7

[BMO Github Automation]

Authored by https://github.com/rocketsroger
https://github.com/mozilla-mobile/firefox-android/commit/aa64798cdb234dca10f7fd43b80e6fb0e9b46c95
[main] Bug 1859052 - Use fallback URL if user cancelled launching in external app

Comment 8

[Daniel Holbert [:dholbert]]

I just ran into this again today when doing a Safeway pick-up order, and that nudged me to re-test, now that we've got a patch.

I can confirm that we have fixed the situation described in my STR (the second tap on my attached testcase's link does successfully reach example.org), but the real-world situation with Safeway doesn't reliably work, in part because my testcase in comment 0 doesn't fully capture the real-world situation.

There are two issues that are causing this to still not-work, in my real-world scenario (where I've got a text from Safeway which has a short-link that resolves to an intent URI with a S.browser_fallback_url):
(A) When you click "Cancel" on the open-in-external-app dialog (step 3 of STR), we don't proactively load the fallback URL. (I suspect maybe/probably we should?) So the user ends up looking at a blank page.
(B) At that point, when I go back to my SMS from Safeway that has a short-link, and tap the short-link (which resolves to an intent URI), Firefox Nightly does not open a new tab, for some reason. We just refocus the existing tab, without e.g. reloading it. So I'm still looking at a blank page.

I'll file new bugs on these.

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #8)

There are two issues that are causing this to still not-work, in my real-world scenario (where I've got a text from Safeway which has a short-link that resolves to an intent URI with a S.browser_fallback_url):
(A) When you click "Cancel" on the open-in-external-app dialog (step 3 of STR), we don't proactively load the fallback URL. (I suspect maybe/probably we should?) So the user ends up looking at a blank page.

I filed this as bug 1882137.

(B) At that point, when I go back to my SMS from Safeway that has a short-link, and tap the short-link (which resolves to an intent URI), Firefox Nightly does not open a new tab, for some reason. We just refocus the existing tab, without e.g. reloading it. So I'm still looking at a blank page.

I filed this as bug 1882142.