1847273 - If you cancel the "Open in another app" dialog, there's no option to be prompted again, aside from force-quitting or waiting an hour

Status: NEW

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

Description

[Daniel Holbert [:dholbert]]

Steps to reproduce

1. Visit https://onelink.to/zvmem in Firefox on Android.
2. When it pops up an "Open in another app" prompt, tap "Cancel"
3. Visit https://onelink.to/zvmem again (or reload).

Expected behavior

I should be given the option to open in another app again.

Actual behavior

I just get a blank page. No prompt appears. There doesn't seem to be any way to get the prompt to appear again.

Device information

• Firefox version: 118.0a1 Nightly. (I've also tested 116.0 release & confirmed that it's affected) Update: see next comment
• Android device model: Pixel 6a
• Android OS version: 13

Any additional information?

This particular URL is the "short link" to access the Android app installer to get the "mobile key" app for Mozilla's new office in a San Mateo co-working space. I received it in a welcome email, and I initially canceled out of the "open in other app" prompt because I wasn't sure I wanted to click through. But then when I decided that I did want to click through, there was no way to do so (i.e. no way to nudge Fenix to give me that prompt again, without forcibly quitting & restarting the app).

Comment 1

[Daniel Holbert [:dholbert]]

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

• Firefox version: 118.0a1 Nightly. (I've also tested 116.0 release & confirmed that it's affected) Update: see next comment

Actually: I thought I tested 116, but I can't reproduce in Firefox 116 right now -- I get the prompt as-expected every time I try to load this URL (even if I hit cancel). So the lack-of-a-prompt in Nightly might be a recent regression.

Firefox Beta 117.0b3 is never giving me a prompt right now, FWIW (even on first load of the page), so 117.0b3 may be affected by this issue or a related more-severe version of the issue.

Comment 2

[jackyzy823]

Fenix add app links do not open cache in memory to avoid prompting user for the same app. See https://github.com/mozilla-mobile/firefox-android/pull/2739 and https://github.com/mozilla-mobile/firefox-android/pull/2978

According to the code, the cache will expired after one hour.

Comment 3

[Daniel Holbert [:dholbert]]

Thanks! Sounds like this is a regression from bug 1830348 then. Sort of intended behavior as described there, but possibly this use-case wasn't considered.

Comment 4

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1830348

:royang, since you are the author of the regressor, bug 1830348, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 5

[Roger Yang [:royang]]

yes, this is expected. There are two solutions if you accidentally rejected open links in apps.

1. Use the menu and tap on open links in app.
2. Restart Firefox Android (swipe away and start again). The cache only lives in memory and not on disk. So even though it's one hour, it's only there for the current session.

Please confirm that one of these solutions works for you.

The reason we didn't have any way of reverting your decision is because we wanted a simple solution without a big UI overhead. Once you reject open links in apps prompt, it will only remember during this session (restart clears it) or an hour. Thanks,

Comment 6

[Daniel Holbert [:dholbert]]

RE "accidentally rejected" -- let me add one more more-realistic user-story here: in my real-world use-case, I didn't really "accidentally reject" the dialog.

Really, I saw the prompt, felt temporarily suspicious/paranoid, wanted to do some quick research before granting, and also wanted to see if I could still get where I needed after clicking cancel [e.g. if the web page provided some useful fallback instructions that didn't require this dialog]. Unfortunately, this particular website's failure-mode is not graceful; it doesn't even load a website. It just checks your UA and (on Android devices) redirects to the URL market://details?id=com.zvworkplace.member

In reply to Roger Yang [:royang] from comment #5)

There are two solutions if you accidentally rejected open links in apps.

1. Use the menu and tap on open links in app.

This doesn't work, because no web page actually loads here. (If you e.g. view this bug and tap the URL in comment 0 and hit cancel on the dialog, you end up still looking at Bugzilla.)

2. Restart Firefox Android (swipe away and start again).

This does work, but it's not particularly discoverable or user-friendly. Also: when exploring this bug, I noticed that some of the time, swiping away didn't actually seem to quit Firefox -- e.g. I'd swipe it away and then reopen Firefox, and it would come back up without needing to re-launch.

(Also: when this "works", it subjectively feels like "Whelp, I guess Firefox broke. I'm glad I was able to get it working again by restarting it.")

Please confirm that one of these solutions works for you.

(2) sort of does, but as noted, it's not great.

The reason we didn't have any way of reverting your decision is because we wanted a simple solution without a big UI overhead.

I understand that, but also recognize that this seems super-mysterious for the use-case where I tripped over this -- Firefox offers to open the external app once, and then never does again, which just looks like something's broken.

Maybe we could make our behavior here a bit more conditional on whether we think the user has "open in app" available in the Firefox menu? If they do have that available, then blocking the dialog seems less troublesome since there's a discoverable workaround. (This would address the scenario in bug 1830348 which was for Amazon, which does have an "open in app" option.)

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

To take the original "onelink.to" URL out of the equation -- here's a reduced testcase that might make this a bit clearer, where the new behavior results in not-great UX (users needing to restart their browser).

STR:

1. Open this testcase in Firefox on an Android device.
2. Tap the link.
3. Notice the prompt, tap Cancel [just because you're not ready or not yet comfortable, let's say]
   [Stuff becomes broken: From this point on, you can't follow the website's instructions anymore, unless you restart Firefox.]
4. Tap the link again. Notice that nothing happens.
5. Reload the site. Tap the link again. Notice that nothing happens.
6. Close and reopen the tab. Tap the link again. Notice that nothing happens.
7. Check for an "Open in app" menu entry. (No such entry exists.)

Comment 8

[Daniel Holbert [:dholbert]]

For comparison, with the attached "testcase 1":

• Chrome just directly opens the play store when I tap the link. (not even a prompt.)
• Firefox release (v116) opens a dialog every time I tap the link.

Comment 9

[Daniel Holbert [:dholbert]]

This issue also creates a "brokenness-at-a-distance" type issue. e.g. suppose you have two different sites that happen to have links to open the same external app, and you want to disallow one but allow the other. With our current behavior, that's not possible anymore.

STR for that:

1. Load https://jsfiddle.net/dholbert/egq9x1up/ which also has a tappable play-store link. Pretend it's a site you don't entirely trust.
2. Tap the link in that fiddle, and then tap "Cancel" on the dialog (since we're pretending this jsfiddle is a site that you don't trust).
3. In another tab, load my attached testcase 1. Pretend that this one is a site you do trust.
4. Tap the link in the testcase, expecting to be able to open the external app (the play store in this case).

EXPECTED RESULTS: I should get a prompt that I can click through to open the external app, from the site-that-I-trust in step 4.

ACTUAL RESULTS: Nothing happens when you tap the link. Firefox is disallowing me from performing an action on a site that I trust, due to some action that I performed (for my own safety) on a site-that-I-didn't-trust, potentially tens of minutes earlier.

Comment 10

[Roger Yang [:royang]]

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

For comparison, with the attached "testcase 1":

• Chrome just directly opens the play store when I tap the link. (not even a prompt.)
• Firefox release (v116) opens a dialog every time I tap the link.

I understand this concern. This was discussed fairly early on why we doesn't just do what Chrome does. Here at Mozilla we want to preserve your privacy. Launching directly into the external app gives your data away to the external app where some users does not want to.

There is an option to behave the same as Chrome. If you set "Open links in apps" to "always", Firefox Android will behave like Chrome.

Comment 11

[Roger Yang [:royang]]

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

I understand that, but also recognize that this seems super-mysterious for the use-case where I tripped over this -- Firefox offers to open the external app once, and then never does again, which just looks like something's broken.

Maybe we could make our behavior here a bit more conditional on whether we think the user has "open in app" available in the Firefox menu? If they do have that available, then blocking the dialog seems less troublesome since there's a discoverable workaround. (This would address the scenario in bug 1830348 which was for Amazon, which does have an "open in app" option.)

This behaviour was added recently due to https://bugzilla.mozilla.org/show_bug.cgi?id=1828454 and similar issues. There are some sites that are prompting the users at every page load to redirect to their external app. This makes browsing the site without redirecting to the app impossible. I added this in hope that can help the users browse these sites in Firefox Android without having to uninstall the external app.

I understand that this current behaviour is not something you want. Maybe there's a compromised solution here? Should we shorten the rejection time? Should we pop a snackbar showing that the user we've blocked it?

Comment 12

[Emilio Cobos Álvarez [:emilio]]

Yeah, I think the current behavior is probably fine fwiw...

Comment 13

[Daniel Holbert [:dholbert]]

(In reply to Roger Yang [:royang] from comment #10)

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

For comparison, with the attached "testcase 1":

• Chrome just directly opens the play store when I tap the link. (not even a prompt.)
• Firefox release (v116) opens a dialog every time I tap the link.

I understand this concern. This was discussed fairly early on why we doesn't just do what Chrome does. Here at Mozilla we want to preserve your privacy. Launching directly into the external app gives your data away to the external app where some users does not want to.

Yup, totally agree that the Chrome behavior is not-great from a privacy perspective, and we don't want to go that far in their direction.

I understand that this current behaviour is not something you want. Maybe there's a compromised solution here? Should we shorten the rejection time? Should we pop a snackbar showing that the user we've blocked it?

Thanks! Yeah, I'm just coming at it from a perspective of "Mozilla's own bay area 3rd-party co-working space trips over this bug when I follow instructions to install a key-card app [if I tap cancel once out of paranoia or by accident]. Probably there are some other users out there who will too, and we don't want to frustrate/lose those users."

My suggested improvement: why not take inspiration from our alert()-spam mitigation? i.e.: if the user hits "Cancel" and then the site asks again, maybe we should add a "Don't allow this site to prompt you again" checkbox on the second prompt? (You can try this out for alert() at data:text/html,<script>alert("a");alert("b");alert("c");</script>; jsfiddle link here) This would of course require that we manage the blocked/unblocked status on a per-site basis (and we would need to make sure that works as-expected for redirectors like the onelink.to use-case.)

Benefits over the current Nightly behavior:

• Users get a low-friction way to reject these prompts, think through the implications, and then try again (as in my STR here)
• It's clearer to users what is going to happen (and which actions will/won't be "sticky")
• It's clearer to users that quitting & restarting Firefox might be a useful workaround, if the user asks Firefox to block requests and then changes their mind (and this doesn't feel as much like "hmm, I guess Firefox broke when I tapped Cancel" and instead feels more like "hmm, I guess Firefox was respecting my expressed intent to stop the site from popping up additional prompts")

Comment 15

[Ryan VanderMeulen [:RyanVM]]

Roger, any thoughts on comment 13?

Comment 16

[Roger Yang [:royang]]

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

Benefits over the current Nightly behavior:

• Users get a low-friction way to reject these prompts, think through the implications, and then try again (as in my STR here)
• It's clearer to users what is going to happen (and which actions will/won't be "sticky")
• It's clearer to users that quitting & restarting Firefox might be a useful workaround, if the user asks Firefox to block requests and then changes their mind (and this doesn't feel as much like "hmm, I guess Firefox broke when I tapped Cancel" and instead feels more like "hmm, I guess Firefox was respecting my expressed intent to stop the site from popping up additional prompts")

I like this idea. But the problem here is if the user ticked "don't ask me again" we need to keep that preference permanent. Right now we keep it in memory but once Firefox restarts it's forgotten. By saving this preference permanent, we need to give user an option to clear that preference, or mange these preferences.

Both of these involves new UX designs.

Comment 17

[Daniel Holbert [:dholbert]]

(In reply to Roger Yang [:royang] from comment #16)

I like this idea. But the problem here is if the user ticked "don't ask me again" we need to keep that preference permanent.

Just to clarify: I didn't intend for any sort of permanence in my comment 13 proposal. In the repeated-spammy-alert() situation that I'm drawing inspiration from (see my jsfiddle above), we only persist the "don't allow any more" setting for the current pageload. So there's no preference-management/clearing UI necessary.

In a perfect world we could persist it for longer and offer UI to clear it, but maybe persisting it for the current pageload would be a good improvement over what we've got right now?

That would still address bug 1830348, I think. It could mean that a potentially mean a spammy app would regain the ability to request its app to be installed each time you navigate from one page to the next, despite the fact that the user checked the "don't ask me again" checkbox. That's admittedly confusing, but it's also arguably less confusing than the current situation where a single "cancel" prevents any further requests for an hour. We do also have "Open links in apps: never" as an option that users could fall back on if they are really running up against that?

Comment 18

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:jonalmeida, could you have a look please?

For more information, please visit BugBot documentation.

Comment 19

[jackyzy823]

To be more clearly, "force-quitting " means "force stop" in "App Info".

Just swiping app from Recents screen do not work. (because the fenix process still exists and so do the cache map). This is quite annoying.

Comment 20

[[e-mail]]

Raising the priority to trigger a conversation about this issue.

Comment 21

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Fenix::App Links' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 23

[Daniel Holbert [:dholbert]]

(In reply to Roger Yang [:royang] from comment #11)

This behaviour was added recently due to https://bugzilla.mozilla.org/show_bug.cgi?id=1828454 and similar issues. There are some sites that are prompting the users at every page load to redirect to their external app. This makes browsing the site without redirecting to the app impossible. I added this in hope that can help the users browse these sites in Firefox Android without having to uninstall the external app.

I wonder if the bucketing in bug 1983915 comment 6 helps somewhat with mitigating this issue, such that maybe we might be able to remove this 1-hour-timeout if/when we address that comment?

Specifically, as an example: if you have the Amazon Shopping app and you visit http://amazon.com, then literally every link on the front page will currently trigger an "Open in Amazon Shopping" prompt, just by virtue of the fact that Amazon Shopping app registers itself as able-to-handle all https://www.amazon.com URIs, I think, and that makes us eagerly-prompt. (Or rather, we prompt until the first time you click "Cancel" at which point no link will trigger that prompt anymore.) I think this is precisely the sort of spamminess that we were trying to address in bug 1830348 when we made "Cancel" sticky -- but really, I'd argue that we should not be launching/prompting at all in this case where the user is just tapping same-site links to navigate around a site that they intentionally loaded in the browser (and notably Chrome does not launch the external app in this case). More thoughts on this in bug 1983915 comment 6, example situation 4 (and bucket B).

So: if we address that (i.e. stop treating same-site navigations as an opportunity to launch an external app), maybe most/all of the spammy-prompting that we tried to mitigate in bug 1830348 would just stop? (I wonder if this was really what was going on with AliExpress in bug 1836971, for example.)

But if there are sites that trigger external-app-launch prompts spammily in other ways (e.g. if their app-handled links happen to be cross-site, or if they use explicit app-specific non-http/https URLs when you tap links/buttons), then maybe some sort of "Stop prompting me for a little while" checkbox (as alluded to in comment 17 here) would still be a better solution for those cases.

Comment 24

[Roger Yang [:royang]]

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

I'd argue that we should not be launching/prompting at all in this case where the user is just tapping same-site links to navigate around a site that they intentionally loaded in the browser (and notably Chrome does not launch the external app in this case).

I agree but not all user will agree on this. They might want to at least be prompted once. I can see some user will ask why they didn't get the option to go to the application.

I think the best solution is still something that is less intrusive than the prompt but still allow the user to make a decision after they hit cancel. Unfortunately this will require some UX discussions. But in my opinion I think a snackbar reminding the user that they hit cancel but allow them to tap on it and launch in external app is one solution. (probably just the first time? that I'm not sure)

Comment 26

[BugBot [:suhaib / :marco]]

The severity field for this bug is set to S3. However, the following bug duplicate has higher severity:

• Bug 1974955: S2

:royang, could you consider increasing the severity of this bug to S2?

For more information, please visit BugBot documentation.

Comment 27

[Andreas Pehrson [:pehrsons]]

See bug 1973897 comment 9 for another case where this behavior is problematic. TL;DR an external app is used for authentication and the user cancels the prompt by mistake: can't login.

STR:

1. Prereq: Have installed https://play.google.com/store/apps/details?id=com.bankid.bus
2. Prereq: Have Open links in apps setting set to Ask before opening
3. Possible prereq: appear to be in Sweden (VPN)
4. Open https://www.hygglo.se/user
5. Tap Logga in
6. Tap Öppna BankID-appen
7. Tap Starta BankID
8. When the prompt to open an external app appears, tap Cancel
9. When the app.bankid.com URL loads in Firefox, tap the back button
10. Do steps 5-7 again

Expected result: prompted to open external app
Actual result: the app.bankid.com URL loads in Firefox immediately

11. Open Firefox settings and set Open links in apps to Always
12. Do steps 5-7 again

Expected result: BankID app opens
Actual result: the app.bankid.com URL loads in Firefox immediately

This breaks a lot of swedish websites relying on digital IDs (mainly BankID but there are others too) for auth after a user mis-taps to Cancel the prompt. Most certainly similar flows are common in other markets too.