1697768 - Opening "localhost:8080" or similar links asks what application should be used to handle "localhost:xxxx" URIs

Status: RESOLVED WORKSFORME

(Core :: DOM: Navigation, enhancement)

Description

[olafur.palsson2]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0

Steps to reproduce:

Open "localhost:8080"

Actual results:

I'm asked what application should handle the URI

Expected results:

Open "http://localhost:8080"

Comment 1

[Andrei Purice]

Setting a component for this enhancement in order to get the dev team involved.
If you feel it's an incorrect one please feel free to change it to a more appropriate one

Comment 2

[Dragana Damjanovic [:dragana]]

What response is received when accessing http://localhost:8080?

The browser is probably getting a response without a content type and it does not know how to handle it.

Comment 3

[snejugal]

I'd like to point out that this only happens when entering exactly localhost:8080, if I enter http://localhost:8080, Firefox correctly opens the page. So Firefox thinks that localhost in localhost:8080 is a custom protocol. This has actually regressed since some version, but I don't remember in which exact version it used to work correctly.

Comment 4

[Tom S [:evilpie]]

Does this happen with flatpak version of Firefox? In that case this is a duplicate of bug 1618094.

Comment 5

[snejugal]

I have Firefox installed from Ubuntu repos

Comment 6

[Valentin Gosu [:valentin] (he/him)]

GIjs, could we fix this in URIFixup? To never query the protocol handler for localhost:port ?

Comment 7

[:Gijs (he/him)]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #6)

GIjs, could we fix this in URIFixup? To never query the protocol handler for localhost:port ?

That would only fix localhost, but not the generic problem. bug 1744243 has what I think is a more thorough suggestion - though perhaps we still need a refinement in that bug to navigate to http:// + input (rather than searching) for input matching [a-z.0-9-]+:[0-9]+ or w/e. Either way, I don't think we need more bugs on file for this. The root cause is that the gtk protocol handler lies, when running under gdk portal / flatpak / whatsit, but apparently upstream are not interested in providing apps with this information and fixing the issue. We should dupe to 1618094, unless I'm missing something?

Comment 8

[Valentin Gosu [:valentin] (he/him)]

I was wondering if we'd want to fix localhost specifically. Even when the platform may have a protocol handler for "localhost", I expect this is not what the user wants to load. SImilar to how bug 1220810 made localhost always be the loopback address.
What do you think?

Comment 9

[:Gijs (he/him)]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #8)

I was wondering if we'd want to fix localhost specifically. Even when the platform may have a protocol handler for "localhost", I expect this is not what the user wants to load. SImilar to how bug 1220810 made localhost always be the loopback address.
What do you think?

I think Marco is better-placed to evaluate this.

Comment 10

[Marco Bonardo [:mak]]

I'm not too keen on adding workarounds for system misconfigurations unless they are knowingly common among our users. Honestly I don't think having a "localhost" protocol registered is so common. The benefit seems extremely thin in this case, compared to things like bug 1220810 that surely affects a wider population.

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

That would only fix localhost, but not the generic problem. bug 1744243 has what I think is a more thorough suggestion - though perhaps we still need a refinement in that bug to navigate to http:// + input (rather than searching) for input matching [a-z.0-9-]+:[0-9]+ or w/e.

I suspect it will just work if the host is in browser.fixup.domainwhitelist.* and localhost is there by default.

Comment 11

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

Redirect a needinfo that is pending on an inactive user to the triage owner.
:masayuki, since the bug doesn't have a severity set, could you please set the severity or close the bug?

For more information, please visit BugBot documentation.

Comment 12

[:Gijs (he/him)]

Redirecting to Marco instead. I expect this would have been fixed by bug 1744243 so we should resolve as works-for-me. Marco?

Comment 13

[Marco Bonardo [:mak]]

it should be fixed indeed.
Of course there's still https://bugzilla.mozilla.org/show_bug.cgi?id=1618094#c60 open: if the user has a "broken" handler registered in handlers.json, we'll try to use that.