1859192 - follow-up: Mailto link does not open default app or query which app to use

Status: RESOLVED FIXED

(Firefox for Android :: App Links, defect)

Description

[Djfe]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0

Steps to reproduce:

:royang Hi Roger,
I got some bad news on this one :/

I just hit Bug 1849368 again on release 118.2.0 on Pixel 7 Pro, Android 14
I just looked at the source and the tag includes your bugfix https://github.com/mozilla-mobile/firefox-android/commits/fenix-v118.2.0

Also affected are:
Beta 119
Nightly 120.0.a1 ()

How to reproduce:
Click on a mailto: link -> it opens the dialog for opening the link in another app: click "cancel" instead of "open"
Every consecutive mailto: link is broken again (until you close fenix from the recent apps list and reopen it again)

Actual results:

same symtoms as last time:
The address bar shows some loading animation for less than 1 second.
Some pages open an about:blank page on click instead, when they use target="_blank"

I'm glad that this time around the bug is less prominent.

Expected results:

Fenix should keep on opening mailto: geo: sms: or tel: links, even if I clicked cancel the last time the dialogue appeared.

I created a new bug report since Bug 1849368 was closed and I have no permission for reopening it.

Comment 1

[Djfe]

Ups, clicked send too early

Also affected are:
Beta 119.0b9
Nightly 120.0.a1 (2023-10-15)

Comment 2

[Djfe]

mailto: geo: sms: and tel: break independently.

If I click cancel on mailto: it only breaks consecutive mailto: links, while sms: still work (unless you click "cancel" in their respective dialogue)

Comment 3

[jackyzy823]

Ref https://bugzilla.mozilla.org/show_bug.cgi?id=1847273#c2

Comment 4

[Djfe]

interesting, thanks for linking that.
this could be related but doesn't have to be since for this bug swiping the app on the recents screen to clear it is enough to get functionality working again.

Comment 5

[Mira Lobontiu (Android QA)]

Attachment: logcat.txt

I was able to reproduce this issue on a Google Pixel 6 (Android 14).
On https://www.w3docs.com/snippets/html/how-to-create-mailto-links.html I tapped on "Send Email" demo option, and "Cancel" on the "Open in another app" prompt --> a new "about:blank" tab opened.

Reproducible on Firefox 118.2.0, Beta 118.0b9, and Nightly 120.0a1 from 10/16.
I'll attach a short video too.

Comment 6

[Mira Lobontiu (Android QA)]

Attachment: az_recorder_20231016_154234.mp4

Comment 7

[Roger Yang [:royang]]

Yes, this is the expected behaviour. If the user taps cancel, we stop trying to open link in apps for an hour or until Fenix restarts.
I've meant to revisit this to make the solution better. I'll use this issue to remind me to implement a better solution or shorten the timing.

Comment 8

[Djfe]

If I press cancel then I might've hit the wrong mailto: link in an Impressum by accident and then want to click the other one after pressing cancel.
Sorry, but Noone would expect any kind of timeout here. Why even?
It's not like this is some abusive Javascript that spams alerts.

Honest suggestion: please remove the timeout altogether. Thank you :)

Where this makes sense:
I'm surfing on songkick.com and it tries to make me open the app all the time instead of letting me surf the site.
But for that reason I have set open links in apps set to never.
But for the same reason I would expect every link that can only be opened in other apps to be the exception. Not timeout necessary.

Or introduce a second button: "Hide for now" instead of "Cancel"

Regardless thanks for explaining why this is. This above is just my opinion. Feel free to decide what you think works best :)
You might have a better idea than me.

Just wanted to say: the current solution is not obvious and thereby kind of bad practice.

Comment 9

[Roger Yang [:royang]]

(In reply to Djfe from comment #8)

Sorry, but Noone would expect any kind of timeout here. Why even?

The reason why we did the timeout is some sites are very aggressive trying to redirect to their own app. To the point that it's attempting to redirect every few seconds so the site becomes unusable. I understand that everyone have a different preference and I'll try to find a solution that works for everyone.

Comment 10

[BMO Github Automation]

Attachment: [mozilla-mobile/firefox-android] Bug 1859192 - Always intercept app links if scheme is not supported by engine (#5080)

Comment 11

[Roger Yang [:royang]]

One solution is that we should not block the app links if our engine can't support the url scheme. Hopefully this is a good middle ground between not getting prompted all the time and not blocking important applinks such as mailto: or tel:

Comment 12

[Djfe]

great idea ❤️

Comment 13

[BMO Github Automation]

Authored by https://github.com/rocketsroger
https://github.com/mozilla-mobile/firefox-android/commit/1fac0742c046d36c646bfb5ffdc588ef89e95035
[main] Bug 1859192 - Always intercept app links if scheme is not supported by engine

Comment 14

[Roger Yang [:royang]]

To test this, tap on a mailto or a tel link and tap on cancel when prompted for external app. Then tap on it again to confirm that we will still prompt the user after rejection. Thanks

Comment 15

[Adina Petridean QA [:apetridean]]

Attachment: open with.mp4

Comment 16

[Adina Petridean QA [:apetridean]]

Verified as fixed on Nightly 123.0a1 from 01/10 with Google Pixel 7 Pro ( Android 14).