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

Steps to reproduce:

Type localhost:port on the search bar, for example:
localhost:4563 (if you run a dev app on the port 4563)

Actual results:

Firefox will ask you with what app you want to open url of type "localhost".
So, localhost is not recognized properly as domain name, but as a protocol.

This answer is correct is you type someting like protocol://something, for example: localhost://port. But this is not what I typed.

http://something
https://something
steam://game
tg://whatever

But not with host:port

Expected results:

Firefox have to open http://localhost:port instead of asking to select an app to open this url.

The workarround is to specify "http://" before localhost, but this is a waste of time, it worked before.

I am setting the (Core) Networking component as it seems to be closely related to it.
Furthermore, I can't reproduce it because I don't know how to host an application (hosting python's simple server does not reproduce it, but correctly opens directory listing of own PC).

If I have a test case of some kind, I could attempt to find its regressor. Thank you.

Hello,
I have uploaded a video to show you the regression:
https://www.youtube.com/watch?v=RBMPpqvLFys

You don't need a running server on a local port to get this bug, I tried a random port of my machine without any app running, and it does the same thing.

Without http:// → it doesn't recognize the address (regression, a pain for web developers)
With http:// → it works (normally)

I hope this will help you,
Thank you :)

I also have this problem.

I cannot reproduce this.
do you have any addon installed? Do you have any prefs changed?

you can look at about:support to find a list of prefs.

Hello,
I'm sorry but I have this issue on Firefox 84.0.2 on Ubuntu, even in safe mode (without all addons).
I have a screenshot for this, but I can't add the screenshot to my post (no upload in message options).

This looks like a recent regression.
Could you try to use mozregression to find out which patch causes this problem?

THanks.

Hello,
I have checked all builds from 2020-05-01 and 2021-02-01 with moz-regressions (nightly, and releases), and I can't reproduce the problem.
But, I always have the problem on Firefox 84.0.2, so I checked something else:

• I run Kubuntu in VM with Firefox 79.0, and... no problem, even with Plasma Integration extension.
• I run Kubuntu in VM with Firefox 84.0 and... no problem, even with Plasma Integration extension.
• I run KDE Neon in VM with Firefox 84.0 and... I have the problem, with or without Plasma integration extension.
  (All tests with clean vm, no profiles, no other addons, etc...)
  (No problem on windows with Firefox 84.0.1 and 85.0)

But:

• On the KDE Neon, where I have the problem, if I run a version of firefox 84, or 85 downloaded from mozilla.org (tar.gz), I don't have any problem.
  So, Neon can be the problem, but... with official release, it's not a problem...

I check the source of the package, and, the Firefox version for KDE Neon is packaged by Ubuntu. (it's not a specific package for KDE Neon)
So, this is maybe the source of the problem, but at this time, I cannot say what in this package cause the problem.
Maybe Ubuntu specific modifications for their needs?

I will try to find the source of this problem...

I just loaded the KDE Neon into virtual box and I can reproduce this with the Live CD.

It seems the in the URIFixup service that we find the external protocol handler can handle a "localhost" scheme.
Marco, you last made changes around this code. Could you take a look?

I suspect we may want to special-case localhost?

I'm fairly sure this is a dupe of bug 1618094, and the problem is with flatpak or xdg-desktop-portal or something, as it likes to pretend it understands every protocol, no matter how nonsensical. And yes, we could specialcase localhost but (a) that doesn't really fix all of the problem and (b) it's not actually a problem caused (or fixable) by us. AIUI there's discussion with the people who do have options to fix this problem, as per the last comments in 1618094.

Valentin, can you confirm if this seems correct, or if there's a separate, special KDE Neon problem here?

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

I'm fairly sure this is a dupe of bug 1618094, and the problem is with flatpak or xdg-desktop-portal or something, as it likes to pretend it understands every protocol, no matter how nonsensical.

That seems to be correct. Every string I pass into ext.externalProtocolHandlerExists("string") returns true, so this is likely a dupe.
Thanks for the info.

The problem is:

• The ubuntu package is not in a flatpak environment, it's installed via apt

But, maybe it's caused by a service like this, this can be because the same package bug on Neon, and not on Kubuntu.

But, I don't understand why with the version from the tar.gz (from mozilla.org), on KDE Neon, there is no problem, why only on the apt version?
And why the same apt version bug only in KDE Neon?

This problem is like a fork bomb if the user select "Firefox" as default program to open this URL:

• Firefox call firefox, and then call firefox, and then call firefox, and it creates indefinitely new tabs with the localhost url.

This seem to be not localhost specific, if I type:

google:4512
I get the same result.

I tried:
google.fr:4851

And I get the same result.
So, every address which not starts with http or https, and that is not select from a previous history URL (correctly loaded previously, and who has http/https), is considered as external URL with this bug.

So, this is not localhost specific.... I will try something else with Kubuntu to try to find the source of the problem...

Something new I see when I upgrade from Kubuntu to KDE Neon is that Firefox can open all files with the "System handler" by default. This can be good to fix another bug, where firefox open pdf with google chrome by default instead of okular in the system preferences....but in reality, for PDF firefox doesn't select "System handler" but "Google Chrome", I don't know why, but this is also a pain... (I use firefox as default web browser, it's not to use google chrome for pdf...)

But I don't know why the tar.gz version is not affected like the apt version...

I continue to investigate.... maybe someone from KDE Neon could have the answer?

Ok, I have tested with Kubuntu 20.04.1:

• With GTK_USE_PORTAL=1 in the environment, the problem is also on Kubuntu.
• But, without the portal, it's ok, no problem.
  With KDE Neon, I suppose that this behaviour is enabled by default somewere, because I have KDE dialogs in Firefox.

I have also tested on Ubuntu 20.10 with GNOME:

• With GTK_USE_PORTAL=1, the problem is even on GNOME.

So, ok, it seem to be a problem with the portal, like you said before...

Ok, I just installed the firefox 85 upgrade with apt (upgrade available just now), and this fix the problem on neon. (even with portal enabled)
Thanks to the person who fix this problem :D

Going to re-dupe this because the original issue in terms of compat between desktop-portal and Firefox is still not fixed.

Yes, and the "fix" for this problem cause now that links to other apps doesn't work: appstream:// snap:// or steam:// links doesn't work... so this fix a problem but create another one..

I don't know if this bug was really fixed or not, but it seems to be still here on Firefox 96 on KDE Neon...

(In reply to valentin from comment #17)

I don't know if this bug was really fixed or not, but it seems to be still here on Firefox 96 on KDE Neon...

It wasn't marked fixed, it was marked as a duplicate of bug 1618094, which is still open. Please do not leave "me too" comments on open bugs.