1773792 - No user feedback when clicking a link that uses an unrecognized protocol

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[jake]

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

Steps to reproduce:

1. Visit website with tel: or geo: links which have no system support.
2. Click on link.

Actual results:

Nothing.

Expected results:

Some kind of error message indicating the link type is not supported.

Notes:

1. Right-clicking and opening in new tab results in "The address wasn’t understood" error page.
2. This used to happen for direct (left) clicking, but something has changed recently, which means the user has no feedback that the protocol is not supported.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 2

[jake]

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

Bugbot is rubbish as usual.

Comment 3

[jake]

I don't have the privilege to change the Component.

Comment 4

[Andrew McCreight (out of office until 8/21) [:mccr8]]

Gijs, do you know what might have changed here?

Comment 5

[:Gijs (he/him)]

Probably bug 1528305.

I can repro with:

data:text/html,<a href="geo:hello">Click

Emilio?

Comment 6

[:Gijs (he/him)]

Huh, though that change is pretty old, and comment 0 says "recently". Reporter: when did this last work for you? If you're happy with a commandline and/or python apps, you can use https://mozilla.github.io/mozregression/ to check.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 8

[jake]

Huh, though that change is pretty old, and comment 0 says "recently". Reporter: when did this last work for you? If you're happy with a commandline and/or python apps, you can use https://mozilla.github.io/mozregression/ to check.

I would guess more "recently" than that bug 1528305 was fixed, but cannot be certain. This is the first time I've seen the new behaviour, but I don't habitually click links with protocols I know won't work, except occasionally when testing my own sites.

The previous behaviour was that such links would open a new tab (regardless of target), then the error would displayed.

If I find time, I will try the regression check.

Comment 9

[jake]

(In reply to jake from comment #8)

I would guess more "recently" than that bug 1528305 was fixed, but cannot be certain.

Though having looked at the other bug I am inclined to think that "recently" could plausibly be more than 2 years ago.

Comment 10

[Emilio Cobos Álvarez (:emilio)]

Attachment: What Emilio sees in a clean Nightly profile

I don't see that behavior here on Linux, this is what I see. What am I missing?

Comment 11

[:Gijs (he/him)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #10)

Created attachment 9281367 [details]
What Emilio sees in a clean Nightly profile

I don't see that behavior here on Linux, this is what I see. What am I missing?

The case in this bug is what happens for protocols that we do not know how to handle.

Based on the screenshot, I guess you have an app on your OS that can handle geo? I do not... If that's the case you can substitute gobbledygook for geo and see if you can repro.

Another explanation could be that you're using a flatpak/snap build which lies and pretends you can open every protocol (see bug 1618094). macOS and Windows don't do that.

Comment 12

[Emilio Cobos Álvarez (:emilio)]

Yeah, I get protocol handlers for geo:. But anyways I think our behavior is not too terrible. If we navigated like we did before bug 1528305, we would give the site the information of whether the protocol is supported or not.

We could add some sort of error message, I suppose... What do other browsers do? On Linux, Chromium always uses xdg-open (so you get an annoying popup and then nothing, which is pretty bad).

Comment 13

[:Gijs (he/him)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #12)

Yeah, I get protocol handlers for geo:. But anyways I think our behavior is not too terrible. If we navigated like we did before bug 1528305, we would give the site the information of whether the protocol is supported or not.

We could add some sort of error message, I suppose... What do other browsers do? On Linux, Chromium always uses xdg-open (so you get an annoying popup and then nothing, which is pretty bad).

Chrome also does nothing, at least on macOS. If you open in a new tab, you get about:blank but with the custom URL in the address bar (which makes no sense).

Maybe this is wontfix?

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 15

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Hello,
I tested using data:text/html,<a href="geo:hello">Click until I could trigger the error page with a left click. I ran mozregression and it pointed me to the following:

• last good: 2020-03-31
• first bad: 2020-04-01

pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9af589864188fc4061a020c45914f54fa9f67b0d&tochange=205d1b4e8f6946fa8ef35c86febdd338c1159715

Please let me know if there's anything else I can do to help.

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 17

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

(In reply to :Gijs (he/him) from comment #13)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #12)

Yeah, I get protocol handlers for geo:. But anyways I think our behavior is not too terrible. If we navigated like we did before bug 1528305, we would give the site the information of whether the protocol is supported or not.

We could add some sort of error message, I suppose... What do other browsers do? On Linux, Chromium always uses xdg-open (so you get an annoying popup and then nothing, which is pretty bad).

Chrome also does nothing, at least on macOS. If you open in a new tab, you get about:blank but with the custom URL in the address bar (which makes no sense).

Maybe this is wontfix?

Chrome does nothing on Win11, too.

From the regression window https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9af589864188fc4061a020c45914f54fa9f67b0d&tochange=205d1b4e8f6946fa8ef35c86febdd338c1159715 https://bugzilla.mozilla.org/show_bug.cgi?id=1597154 looks the suspicious one?

Comment 18

[jake]

(In reply to Hsin-Yi Tsai (Fx104 REO) [:hsinyi] from comment #17)

(In reply to :Gijs (he/him) from comment #13)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #12)
Maybe this is wontfix?

Chrome does nothing on Win11, too.

From the regression window https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9af589864188fc4061a020c45914f54fa9f67b0d&tochange=205d1b4e8f6946fa8ef35c86febdd338c1159715 https://bugzilla.mozilla.org/show_bug.cgi?id=1597154 looks the suspicious one?

Just because Chrome has the same bug is not a reason to close as 'wontfix'. We should aspire to make FF better than Chrome, so that people choose to use it for that reason (as well as the obvious political reason and availability of add-ons which keeps the current user-base). Also, as pointed out and confirmed, this is a regression in FF.

Comment 19

[:Gijs (he/him)]

(In reply to Hsin-Yi Tsai (Fx104 REO) [:hsinyi] from comment #17)

Chrome does nothing on Win11, too.

From the regression window https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9af589864188fc4061a020c45914f54fa9f67b0d&tochange=205d1b4e8f6946fa8ef35c86febdd338c1159715 https://bugzilla.mozilla.org/show_bug.cgi?id=1597154 looks the suspicious one?

I don't really have anything useful to say here and am not sure what the needinfo request on me is about. That bug suggests that prior to that fix, we would end up in an infinite loop and also not show an error page, which isn't any better, so "regression" seems tenuous if that window is accurate. That fix only landed 3 days after Emilio's changes in bug 1528305 so they seem related. I wasn't involved in either the fixes or the reviews there so I don't really have much context. Can you clarify what you're looking for from me - or perhaps ask Emilio/Nika/other DOM folks to take a look if you think something needs to happen here?

Comment 20

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

(In reply to :Gijs (he/him) from comment #19)

(In reply to Hsin-Yi Tsai (Fx104 REO) [:hsinyi] from comment #17)

Chrome does nothing on Win11, too.

From the regression window https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9af589864188fc4061a020c45914f54fa9f67b0d&tochange=205d1b4e8f6946fa8ef35c86febdd338c1159715 https://bugzilla.mozilla.org/show_bug.cgi?id=1597154 looks the suspicious one?

I don't really have anything useful to say here and am not sure what the needinfo request on me is about. That bug suggests that prior to that fix, we would end up in an infinite loop and also not show an error page, which isn't any better, so "regression" seems tenuous if that window is accurate. That fix only landed 3 days after Emilio's changes in bug 1528305 so they seem related. I wasn't involved in either the fixes or the reviews there so I don't really have much context. Can you clarify what you're looking for from me - or perhaps ask Emilio/Nika/other DOM folks to take a look if you think something needs to happen here?

Gijs, thanks for the comment and sorry that my request wasn't clear.

Since QA provided a wider regression range, I was looking for confirmation of the exact regression commit as bug 1528305 wasn't in that range, and also seeking to understand if we see an acceptable way to revert to the previous behavior. Or are we thinking WONTFIX makes more sense, given the same behavior on Firefox and Chrome, at least on Win11 an MacOS? And ... agreed that the needinfo should have been to Emilio :)

I had set the severity S4 according to comment 12 I think our behavior is not too terrible. and comparison with other browsers. Let me know if we should change that.

Comment 21

[:Gijs (he/him)]

(In reply to Hsin-Yi Tsai (Fx104 REO) [:hsinyi] from comment #20)

Since QA provided a wider regression range, I was looking for confirmation of the exact regression commit as bug 1528305 wasn't in that range, and also seeking to understand if we see an acceptable way to revert to the previous behavior. Or are we thinking WONTFIX makes more sense, given the same behavior on Firefox and Chrome, at least on Win11 an MacOS? And ... agreed that the needinfo should have been to Emilio :)

ISTM from what Emilio said that reverting to showing an error page isn't on the cards as it'd cause privacy/security leakage, but let's check. :-)

Comment 22

[Emilio Cobos Álvarez (:emilio)]

Yeah, if you navigate the page, then the page can tell whether you have a protocol handler for that protocol.

Comment 23

[jake]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #22)

Yeah, if you navigate the page, then the page can tell whether you have a protocol handler for that protocol.

Though if clicking the link produced a simple error message box provided by the browser (instead of silence as at present), presumably that would not be the case.

Comment 24

[:Gijs (he/him)]

(In reply to jake from comment #23)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #22)

Yeah, if you navigate the page, then the page can tell whether you have a protocol handler for that protocol.

Though if clicking the link produced a simple error message box provided by the browser (instead of silence as at present), presumably that would not be the case.

It would, the webpage will be able to tell focus moves, and potentially about occlusion due to mousemove/mouseover events being affected. I don't know if that's sufficient reason not to do it - the other problem is that a "simple error message box" is not likely to be very user friendly or actionable for users, so the value is pretty limited either way.

Comment 25

[jake]

(In reply to :Gijs (he/him) from comment #24)

(In reply to jake from comment #23)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #22)

Yeah, if you navigate the page, then the page can tell whether you have a protocol handler for that protocol.

Though if clicking the link produced a simple error message box provided by the browser (instead of silence as at present), presumably that would not be the case.

It would, the webpage will be able to tell focus moves, and potentially about occlusion due to mousemove/mouseover events being affected. I don't know if that's sufficient reason not to do it - the other problem is that a "simple error message box" is not likely to be very user friendly or actionable for users, so the value is pretty limited either way.

It can use that method as things are at present anyway, can't it? Because if there's a loss of focus for the page or occlusion due to the 'Choose an application to open the link' dialog box, there is a handler, otherwise there isn't.

Following on from that, would not enhancing the 'Choose an appliation to open the link' dialog box to alternatively have the text 'There are no applications available which can open this link' and be shown in all situations (unless the user has previously checked 'always use this application') actually increase security/privacy, as well as being fairly straightforward to implement?

Also if I click, say a geo: or tel: or whatever link, and there is no handler, shouldn't I have the option to choose an application anyway, in the way that there is currently an option 'Choose another application' when there is at least one handler set up?

Comment 26

[jake]

status-firefox104: affected → wontfix

Every time I see this I am worried you have decided not to fix this important UX issue.

I appreciate it will take time to fix properly, and that it should be fixed properly.

Best,
J_

Comment 27

[Dianna Smith [:diannaS]]

(In reply to jake from comment #26)

status-firefox104: affected → wontfix

Every time I see this I am worried you have decided not to fix this important UX issue.

I appreciate it will take time to fix properly, and that it should be fixed properly.

Best,
J_

:jake, hehe, it just means we ran out time in the current cycle to roll out with the 104 release.