Firefox 69 marks both 127.0.0.1 AND localhost as Secure Context.
What is missing, is support for *.localhost (see details in https://bugzilla.mozilla.org/show_bug.cgi?id=1433933#c6)

The uploaded patch is just a WIP however it also resolves a few other issues including Bug 1488740 and that we don't relate this code to the proxying code and that we have a separate allowlist there.

:estark37 & :mkwst is there any interest in Chrome implementing support for alternate ipv4 loopback addresses as mentioned in Comment 4? I didn't implement this purely because I didn't want a compatibility issue.

Now that I have made ipv6 resolve to ::1 Try is even less happy as there are a few tests that require the ability to proxy localhost. This we can fix with the hijack pref however we also then treat it as insecure when it's proxied which I think is the right thing to do however some of the tests require this also.
Try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=a3e647c764c9abca31e0524f108dd34e9e50cf28

Since this bug is open for more than 4 years I want to stress this:
We are affected here by using atlassian companion app for attachment editing in confluence. A recent problem made itnecessary for attlassian to use non-secure localhost content here. It doesn't work right now with ESR version without setting network.websocket.allowInsecureFromHTTPS to true which would mean more security risks. My guess is that this is affecting many companies that are still using firefox.

:estark37 & :mkwst is there any interest in Chrome implementing support for alternate ipv4 loopback addresses as mentioned in Comment 4? I didn't implement this purely because I didn't want a compatibility issue.

We currently resolve localhost to 127.0.0.1 and ::1 as Emily noted. It seems reasonable to extend that to support any /etc/hosts assertions that fall into 127.0.0.0/8, but that's not something we've heard a whole lot of interest in, though there have certainly been one-off requests. I don't think I'd prioritize that work, given the way things have played out over the last ~4 years, but I don't think it's a bad idea.

Given that I'm unlikely to have long left to work on this I'll continue with the hardcoding of loopback instead based on Comment 28. I think this is sufficient in reaching our short term goal here and given 4 years have passed with Chrome I think we can say the interest isn't perhaps worth the additional time.

Try push here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1f81c50581ed3b3b1c34f71dfda10acb27bfa3e9

dragana + ckerschb, I don't know if we can r+ patches outside of phab however this is the same patch with the amendments made. I ditches the effort to try and resolve the address first and filter out non loopback.

I'm still waiting on try which I think has many failures still due to tests expecting loopback to be proxyable whilst also being secure. However if the patch is ok I can clean up these tests, either by removing them or making them use a different hostname perhaps.

See comment 31

• img_url: url("chrome://browser/skin/connection-mixed-active-loaded.svg"),

Doesn't that file need to be registered as supportfile for that test in some
way?

No it's not needed. It's not part the test, it's a required image of the browser package. I'm going to push this patch + your comments to phab.

Backed out changeset f01596089356 for causing crashes in test_performance_attributes_exist_in_object.html

Backout link: https://hg.mozilla.org/integration/autoland/rev/2bf5bbb849934ef9a8b60d1e9b73d919b622f832

Push with failures: https://treeherder.mozilla.org/?#/jobs?repo=autoland&group_state=expanded&resultStatus=success%2Ctestfailed%2Cbusted%2Cexception%2Crunnable&searchStr=%28wpt&fromchange=d405a129956e8714fe211844a72ee5db2c97d5f6&tochange=2bf5bbb849934ef9a8b60d1e9b73d919b622f832&selectedJob=293870518

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=293870518&repo=autoland&lineNumber=20434

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
It would be great for developers if this could land.
Is the assigned field still correct?

Landing mentioned patch is also crucial for providing Secure Context with proper Origin separation for websites loaded from a local IPFS node via *.ipfs.localhost URLs.

(Chromium already follows RFC6761 and it works as expected, but Firefox 75 still hits the OS DNS resolver, so we need to use HTTP proxy for *.localhost to ensure subdomains work on systems with simpler DNS resolvers, such as Debian 10. And, for some reason, subdomains are missing Secure Context attribute, which is present on localhost itself)

Any way we can help getting this across the finish line?

Hm, looks like the test crash is caused by bug 1436778, which baku noted with that dependency... however, bug 1436778 is a two year old hard-to-repro crash bug :(

Adding request for adding to webcompat list, since this works as expected in Chromium.

(In reply to Marcin Rataj from comment #41)

And, for some reason, subdomains are missing Secure Context
attribute, which is present on localhost itself)

Hm, separate bug?

(In reply to Dietrich Ayala (:dietrich) from comment #42)

(In reply to Marcin Rataj from comment #41)

And, for some reason, subdomains are missing Secure Context
attribute, which is present on localhost itself)

Hm, separate bug?

That looks like it will be fixed by this bug. See https://hg.mozilla.org/integration/autoland/rev/f01596089356#l13.80

Matthew is right. The idea is that web developers can use localhost and dev.localhost and really [anything.including.multiple.labels].localhost on their own machine and get a secure context. This will make web development a bit simpler again, especially given https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/.

This does not solve multiple web developers wanting to use a local server together. In that case Mozilla's advise would be to acquire a test domain name, point it to that server, and use Let's Encrypt or other CA to get certificates for that server.

Adding dev-doc-needed to ensure we put all of this on MDN and in the release notes as once this is fixed this will work at least across Chrome and Firefox which is a pretty big win for web developers.

Andrea, why does bug 1436778 block this? Tentatively assigning to you per the last patch.

With this patch, the lookup of "localhost" domains is faster. And this makes bug 1436778 more visible.
DocumentChannel introduces a regression in the way we start and count a few timers for the navigation.

I've recently switched to Firefox as my main browser during web development and the lack of built-in *.localhost support add non-trivial complication to the process of setting up the work station (e.g. after a clean OS install). Having to run your own DNS service and/or listing each service manually with sudo-edited /etc/hosts isn't great :)

(In reply to Andrea Marchesini [:baku] from comment #45)

With this patch, the lookup of "localhost" domains is faster. And this makes bug 1436778 more visible.
DocumentChannel introduces a regression in the way we start and count a few timers for the navigation.

Hi Baku, are you still working on that?

This bug is a serious blocker for us in making localhost applications more secure in Firefox. Works in Chrome, which makes it very hard to recommend Firefox while this isn't fixed.

Is this blocked on engineering availability only? Baku, if you do not foresee availability soon, maybe we can find help?

The blocker here is bug 1436778. We need to fix that before landing my patch.
If somebody has time to complete bug 1436778, it would be great.

Why is this patch adding a new assertion for the PerformanceTiming constructor? That seems somewhat unrelated to the rest of the changes.

The failing test here (test_performance_attributes_exist_in_object.html) is checking PerformanceTiming for a Document loaded within an <object>.

<object> doesn't create a docshell until we get a response from the network (and know that it's a Document content type), so it's somewhat expected that connect start would be before navigation start.

Backed out changeset 36f368ba214c (Bug 1220810) for causing gecko decision task bustages.

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&searchStr=Gecko%2CDecision%2CTask%2Copt%2CGecko%2CDecision%2CTask%2C%28D%29&tochange=ae539955e4549f4d99df6435d7c9b73cd6189072&fromchange=262677293e2019ee6d6823b604baf3758da5789a&selectedTaskRun=HYmj_Sc1RhGwHVFEvQ277w.0

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=309295235&repo=autoland&lineNumber=1549

Backed out changeset 1b035d80fb9f for causing bustages in netwerk/dns/DNS.cpp

Backout link: https://hg.mozilla.org/integration/autoland/rev/795d407632bb07ab73a833647650d5cd363c3951

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception%2Crunnable&tochange=795d407632bb07ab73a833647650d5cd363c3951&fromchange=1b035d80fb9fcc7dbe0aaf409e02197a967d57a5

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=309319233&repo=autoland&lineNumber=32881

Backed out for bc failures on browser_fall_back_to_https.js

Backout link: https://hg.mozilla.org/integration/autoland/rev/f63d3e3a04b8594f904712fde0f57da6e77a6f27
Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=309324520&repo=autoland&lineNumber=4040

Also xpcshell failures on:

1. test_dns_offline.js -> https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=309325882&repo=autoland&lineNumber=3702
2. test_http3.js -> https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=309325756&repo=autoland&lineNumber=5508
3. test_seizepower.js -> https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=309325774&repo=autoland&lineNumber=4042

I've rebased the patch and was able to tweak the tests to make all but one (browser_fall_back_to_https.js) pass. I'm afraid I'm not familiar enough with the code to understand what's happening, any idea? See https://phabricator.services.mozilla.com/D92716#3020565

(In reply to Frédéric Wang (:fredw) from comment #62)

I've rebased the patch and was able to tweak the tests to make all but one (browser_fall_back_to_https.js) pass. I'm afraid I'm not familiar enough with the code to understand what's happening, any idea? See https://phabricator.services.mozilla.com/D92716#3020565

It may not be related, but I did notice that in netwerk/test/unit/test_ping_aboutnetworking.js and dom/webauthn/tests/browser/browser_webauthn_ipaddress.js, the corresponding clearUserPref("network.proxy.allow_hijacking_localhost") is missing.

(In reply to Mathew Hodson from comment #63)

(In reply to Frédéric Wang (:fredw) from comment #62)

I've rebased the patch and was able to tweak the tests to make all but one (browser_fall_back_to_https.js) pass. I'm afraid I'm not familiar enough with the code to understand what's happening, any idea? See https://phabricator.services.mozilla.com/D92716#3020565

It may not be related, but I did notice that in netwerk/test/unit/test_ping_aboutnetworking.js and dom/webauthn/tests/browser/browser_webauthn_ipaddress.js, the corresponding clearUserPref("network.proxy.allow_hijacking_localhost") is missing.

Right, I think they probably should. Note that I didn't change or check these two tests in details, this was just copied from the original https://phabricator.services.mozilla.com/D64586. I don't know exactly how prefs are reset between tests, but in any case that probably does not matter for browser_fall_back_to_https.js since 1) I was running this single test locally 2) it fails whether or not the pref is enabled.

(In reply to Frédéric Wang (:fredw) from comment #62)

I've rebased the patch and was able to tweak the tests to make all but one (browser_fall_back_to_https.js) pass. I'm afraid I'm not familiar enough with the code to understand what's happening, any idea? See https://phabricator.services.mozilla.com/D92716#3020565

The test was added for Bug 1002724 - the idea is that entering example.com defaults to http//example.com but in case :80 does not respond, then it should fall back to using https:example.com with port :443. I think the problem is that we don't have any test servers in server-locations.txt that do not respond to port :80 and hence the test uses this workaround to automatically test the fall back to https.

Two options:

• We find some host we can use besides example.com which does not respond to port :80 but to port :443
• Maybe (I am saying maybe) we can just flip the pref to false for allow_hijacking_localhost, but it's better to check with a Necko person.

Thanks Christoph.

Just to clarify browser_fall_back_to_https.js has two subtests:

• example.com redirects to http://example.com ; this one still passes with the patch
• 127.0.0.2 redirects https://127.0.0.2 is broken (whether or not the allow_hijacking_localhost flag is enabled)

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #65)

Two options:

• We find some host we can use besides example.com which does not respond to port :80 but to port :443

Trying that (with 128.0.0.1 or www.itisatrap.org) I'm hitting an ASSERT saying that non-local addresses are disabled:
https://searchfox.org/mozilla-central/source/netwerk/base/nsSocketTransport2.cpp#1331

We can just try to skip that ASSERT, but then we would still need to have a non-local address that rejects :80 and accepts :443 (and without a server config that redirects from :80 to :443).

• Maybe (I am saying maybe) we can just flip the pref to false for allow_hijacking_localhost, but it's better to check with a Necko person.

As I previously said, the test fails whatever the state of allow_hijacking_localhost, but I can't explain it.

I'll take a quick look at the test.

To clarify, the test is failing with your patch but it is working fine without you patch?
can you make a http log with your patch and allow_hijacking_localhost true and another log with allow_hijacking_localhost==false?

(In reply to Dragana Damjanovic [:dragana] from comment #69)

To clarify, the test is failing with your patch but it is working fine without you patch?

I haven't tested without the patch but I assume that it passes with the trunk behavior. And yes it has been failing with the patch since comment 53.

can you make a http log with your patch and allow_hijacking_localhost true and another log with allow_hijacking_localhost==false?

Sure, I'll give another try later.

(In reply to Frédéric Wang (:fredw) from comment #70)

(In reply to Dragana Damjanovic [:dragana] from comment #69)

To clarify, the test is failing with your patch but it is working fine without you patch?

I haven't tested without the patch but I assume that it passes with the trunk behavior. And yes it has been failing with the patch since comment 53.

Sorry I meant https://bugzilla.mozilla.org/show_bug.cgi?id=1220810#c59

I applied your patch and this diff:

diff --git a/docshell/test/browser/browser_fall_back_to_https.js b/docshell/test/browser/browser_fall_back_to_https.js
--- a/docshell/test/browser/browser_fall_back_to_https.js
+++ b/docshell/test/browser/browser_fall_back_to_https.js
@@ -57,7 +57,7 @@ async function test_one(test_obj) {
 add_task(async function test_bug1002724() {
   await SpecialPowers.pushPrefEnv(
     // Disable HSTS preload just in case.
-    { set: [["network.stricttransportsecurity.preloadlist", false]] }
+    { set: [["network.stricttransportsecurity.preloadlist", false], ["network.proxy.allow_hijacking_localhost", true]] }
   );
 
   for (let test of bug1002724_tests) {

And the test started passing. 🤷

Clarification: it only passes if there is no server running on my machine on port 80. 🤔

If your local Linux web server is available on 127.0.0.2:80, the test fails as expected. The test expects the http:// connection to fail to retry via https.
Or does network.proxy.allow_hijacking_localhost unexpectedly rewrite http://127.0.0.2 to http://127.0.0.1?

(If MacOS users can't repro anything: At the moment, the test can't run on macOS as it doesn't support 127.0.0.2 by default: bug 1002724 comment 81).

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

Clarification: it only passes if there is no server running on my machine on port 80. 🤔

Thanks. So I had a Apache server running on the two Linux machines I was running the tests on. And it seems by default http://127.0.0.2/ redirects to the Apache default page, so this explains why the test is failing... Stopping the Apache server makes the test pass. I'll try to send the path to the try server with the flag enabled (I think we haven't done that yet, I was only testing locally so far).

Adds secureonly.example.com:443 to server-locations.txt - this host is only available on HTTPS.
Regenerates certs using ./mach python build/pgo/genpgocert.py command.
Sets network.dns.native-is-localhost pref in test so we don't trigger assertion.

Error:

$ ./mach python build/pgo/genpgocert.py
Traceback (most recent call last):
  File "build/pgo/genpgocert.py", line 208, in <module>
    certificateStatus = constructCertDatabase(build, certdir)
  File "build/pgo/genpgocert.py", line 99, in constructCertDatabase
    openssl = distutils.spawn.find_executable("openssl")
AttributeError: module 'distutils' has no attribute 'spawn'

Depends on D94005

The test should pass with the attached patches.
The problem was that 127.0.0.2 was not being proxied, or even when it was the proxy was still falling back to localhost for port 80.
Using a new special host for this test seems more appropriate.

Thanks that's what I wanted to do in comment 67. How about I just merge your patch in mine and we land everything together?

(also incidentally where can I reach people on matrix/element? I was not able to find your name in #Developers)

(In reply to Frédéric Wang (:fredw) from comment #79)

Thanks that's what I wanted to do in comment 67. How about I just merge your patch in mine and we land everything together?

We can land a stack of commits at the same time.

(also incidentally where can I reach people on matrix/element? I was not able to find your name in #Developers)

I'm in the #necko channel.

Comment on attachment 9182402 [details]
Bug 1220810 - Fix genpgocert.py

Revision D94006 was moved to bug 1672115. Setting attachment 9182402 [details] to obsolete.

Comment on attachment 9182401 [details]
Bug 1220810 - Fix browser_fall_back_to_https.js to use actual host r=ckerschb

Revision D94005 was moved to bug 1672127. Setting attachment 9182401 [details] to obsolete.

Backed out for causing test_dns_offline and fontface-override-descriptor-getter-setter failures

Backout link: https://hg.mozilla.org/integration/autoland/rev/14222fee2852881f1cf91aeb62110e52b2d2a91e

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&collapsedPushes=805300&revision=a5a35a205a44328aaeaf42bb493e7173fbfe0ae2

Failure log xpc: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=319225834&repo=autoland&lineNumber=4294

Failure log wpt5: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=319229997&repo=autoland&lineNumber=8825

"INFO - TEST-START | netwerk/test/unit/test_dns_offline.js
[task 2020-10-21T08:43:40.687Z] 08:43:40 WARNING - TEST-UNEXPECTED-FAIL | netwerk/test/unit/test_dns_offline.js | xpcshell return code: 0
[task 2020-10-21T08:43:40.687Z] 08:43:40 INFO - TEST-INFO took 381ms
[task 2020-10-21T08:43:40.688Z] 08:43:40 INFO - >>>>>>>
[task 2020-10-21T08:43:40.689Z] 08:43:40 INFO - PID 894 | [894, Unnamed thread 7faf7da6eee0] WARNING: XPCOM objects created/destroyed from static ctor/dtor: file /builds/worker/checkouts/gecko/xpcom/base/nsTraceRefcnt.cpp:202
[task 2020-10-21T08:43:40.690Z] 08:43:40 INFO - PID 894 | [894, Unnamed thread 7faf7da6eee0] WARNING: XPCOM objects created/destroyed from static ctor/dtor: file /builds/worker/checkouts/gecko/xpcom/base/nsTraceRefcnt.cpp:202
[task 2020-10-21T08:43:40.691Z] 08:43:40 INFO - PID 894 | Couldn't convert chrome URL: chrome://branding/locale/brand.properties
[task 2020-10-21T08:43:40.691Z] 08:43:40 INFO - PID 894 | [894, Main Thread] WARNING: Couldn't get the user appdata directory. Crash events may not be produced.: file /builds/worker/checkouts/gecko/toolkit/crashreporter/nsExceptionHandler.cpp:2949
[task 2020-10-21T08:43:40.692Z] 08:43:40 INFO - PID 894 | [894, Main Thread] WARNING: Couldn't get the user appdata directory, crash dumps will go in an unusual location: file /builds/worker/checkouts/gecko/toolkit/crashreporter/nsExceptionHandler.cpp:3008
[task 2020-10-21T08:43:40.693Z] 08:43:40 INFO - (xpcshell/head.js) | test MAIN run_test pending (1)
[task 2020-10-21T08:43:40.694Z] 08:43:40 INFO - (xpcshell/head.js) | test pending (2)
[task 2020-10-21T08:43:40.694Z] 08:43:40 INFO - (xpcshell/head.js) | test MAIN run_test finished (2)
[task 2020-10-21T08:43:40.695Z] 08:43:40 INFO - running event loop
[task 2020-10-21T08:43:40.696Z] 08:43:40 INFO - PID 894 | [894, Main Thread] WARNING: Could not get the program name for a cubeb stream.: 'NS_SUCCEEDED(rv)', file /builds/worker/checkouts/gecko/dom/media/CubebUtils.cpp:378
[task 2020-10-21T08:43:40.697Z] 08:43:40 INFO - PID 894 | [908, Unnamed thread 7f464176e040] WARNING: XPCOM objects created/destroyed from static ctor/dtor: file /builds/worker/checkouts/gecko/xpcom/base/nsTraceRefcnt.cpp:202
[task 2020-10-21T08:43:40.697Z] 08:43:40 INFO - PID 894 | [908, Unnamed thread 7f464176e040] WARNING: XPCOM objects created/destroyed from static ctor/dtor: file /builds/worker/checkouts/gecko/xpcom/base/nsTraceRefcnt.cpp:202
[task 2020-10-21T08:43:40.698Z] 08:43:40 INFO - PID 894 | [908, MainThread] WARNING: XPCOM objects created/destroyed from static ctor/dtor: file /builds/worker/checkouts/gecko/xpcom/base/nsTraceRefcnt.cpp:202
[task 2020-10-21T08:43:40.699Z] 08:43:40 INFO - PID 894 | [908, MainThread] WARNING: XPCOM objects created/destroyed from static ctor/dtor: file /builds/worker/checkouts/gecko/xpcom/base/nsTraceRefcnt.cpp:202
[task 2020-10-21T08:43:40.700Z] 08:43:40 INFO - PID 894 | [Socket 908, Main Thread] WARNING: 'NS_FAILED(rv)', file /builds/worker/checkouts/gecko/netwerk/protocol/http/nsHttpHandler.cpp:486
[task 2020-10-21T08:43:40.700Z] 08:43:40 INFO - PID 894 | [Socket 908, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, kKnownEsrVersion) failed with result 0x80004002 (NS_NOINTERFACE): file /builds/worker/checkouts/gecko/toolkit/components/resistfingerprinting/nsRFPService.cpp:673
[task 2020-10-21T08:43:40.701Z] 08:43:40 WARNING - TEST-UNEXPECTED-FAIL | netwerk/test/unit/test_dns_offline.js | onLookupComplete - [onLookupComplete : 17] 0 == 2152398864
[task 2020-10-21T08:43:40.702Z] 08:43:40 INFO - /builds/worker/workspace/build/tests/xpcshell/tests/netwerk/test/unit/test_dns_offline.js:onLookupComplete:17
[task 2020-10-21T08:43:40.703Z] 08:43:40 INFO - /builds/worker/workspace/build/tests/xpcshell/head.js:_do_main:248
[task 2020-10-21T08:43:40.703Z] 08:43:40 INFO - /builds/worker/workspace/build/tests/xpcshell/head.js:_execute_test:577
[task 2020-10-21T08:43:40.704Z] 08:43:40 INFO - -e:null:1
[task 2020-10-21T08:43:40.705Z] 08:43:40 INFO - exiting test"

(In reply to Sandor Molnar from comment #84)

Backed out for causing test_dns_offline and fontface-override-descriptor-getter-setter failures

fontface-override-descriptor-getter-setter seems unrelated, probably it's bug 1669420

I'm not able to reproduce the other failures locally, even by running the whole netwerk/test/unit xpshells with a debug build. I see the management of pref in netwerk/test/unit/test_dns_originAttributes.js was not really good though. I'll investigate...

Remaining failures happen with flag network.http.network_access_on_socket_process enabled for the following tests:

netwerk/test/unit/test_dns_offline.js
netwerk/test/unit/test_dns_originAttributes.js

The patch also forces network.proxy.allow_hijacking_localhost to true for these. The failing assertions are the ones expecting a resolution status=NS_ERROR_OFFLINE, when the actual value is status=0.

Any quick idea why it happens and/or which part of the code I should investigate/modify?

Thanks!

The socket process isn't enabled yet by default.
In the interest of landing this soon I'd suggest disabling the tests on socket process like this

https://hg.mozilla.org/mozilla-central/rev/dfcb025567da

(In reply to Sandor Molnar from comment #84)

Backed out for causing test_dns_offline and fontface-override-descriptor-getter-setter failures

Backout link: https://hg.mozilla.org/integration/autoland/rev/14222fee2852881f1cf91aeb62110e52b2d2a91e

== Change summary for alert #27329 (as of Fri, 23 Oct 2020 09:22:47 GMT) ==

Improvements:

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=27329

FYI Docs for this have been captured in new section Mixed content > Loading locally delivered mixed-resources, in the bullet point

• Firefox 84 and later allow loading of mixed content on http://localhost/ and http://*.localhost/ URLs, as these are now mapped to loopback addresses (see bug 1220810).

After this fix, although I point my dev.localhost hostname to the WSL ip inside hosts file, it is not working. From Chrome any *localhost domain will see the WSL without even requiring anything in the hosts file, from FF it's not working. Any ideas?

(In reply to liakoskonstantin from comment #92)

After this fix, although I point my dev.localhost hostname to the WSL ip inside hosts file, it is not working. From Chrome any *localhost domain will see the WSL without even requiring anything in the hosts file, from FF it's not working. Any ideas?

I have the same problem with .localhost in FF.

liakoskonstantin, Ivan, does it work if you flip network.proxy.allow_hijacking_localhost in about:config? I guess either way this requires some kind of follow-up bug since we wanted to match Chrome.

Frédéric, thoughts?

(In reply to liakoskonstantin from comment #92)

After this fix, although I point my dev.localhost hostname to the WSL ip inside hosts file, it is not working. From Chrome any *localhost domain will see the WSL without even requiring anything in the hosts file, from FF it's not working. Any ideas?

(In reply to Ivan from comment #93)

I have the same problem with .localhost in FF.

I believe this is working as intended. *.localhost are now hardcoded to the loopback device and any attempts to reroute it should be ignored. This is necessary in order to consider http://*.localhost and http://localhost trusted contexts for the purpose of accessing a number of browser features (like USB access for example). If localhost may not point at the loopback device, then it can no longer be considered a trusted context by the browser and thus those features have to be disabled.

(In reply to Anne (:annevk) from comment #94)

liakoskonstantin, Ivan, does it work if you flip network.proxy.allow_hijacking_localhost in about:config? I guess either way this requires some kind of follow-up bug since we wanted to match Chrome.

Frédéric, thoughts?

You are awesome. Yes, with this little hack it worked.

Worth noticing though that in my laptop it worked without issues, the problem was with my desktop. As far as I checked, I had the same settings in both. Couldn't find out why desktop was not working.

Do you want me to provide any additional info?

(In reply to Micah Zoltu from comment #95)

(In reply to liakoskonstantin from comment #92)

After this fix, although I point my dev.localhost hostname to the WSL ip inside hosts file, it is not working. From Chrome any *localhost domain will see the WSL without even requiring anything in the hosts file, from FF it's not working. Any ideas?

(In reply to Ivan from comment #93)

I have the same problem with .localhost in FF.

I believe this is working as intended. *.localhost are now hardcoded to the loopback device and any attempts to reroute it should be ignored. This is necessary in order to consider http://*.localhost and http://localhost trusted contexts for the purpose of accessing a number of browser features (like USB access for example). If localhost may not point at the loopback device, then it can no longer be considered a trusted context by the browser and thus those features have to be disabled.

How can I check where my localhost is pointing?

(In reply to Anne (:annevk) from comment #94)

does it work if you flip network.proxy.allow_hijacking_localhost in about:config?

Yes, now it works.
Many thanks!

(In reply to Anne (:annevk) from comment #94)

liakoskonstantin, Ivan, does it work if you flip network.proxy.allow_hijacking_localhost in about:config? I guess either way this requires some kind of follow-up bug since we wanted to match Chrome.

Frédéric, thoughts?

Sorry, I completely miss this message. Normally, with the default value of network.proxy.allow_hijacking_localhost (false), Firefox should match Chrome's behavior. Setting it to true should only be needed for tests. I'm not sure if people are saying they have the option off or on.

For the WSL issue, maybe it's bug 1670146

There is a bug here you may want to consider.

If the secure context feature must consider *.localhost to be hard-coded to the loopback address, then http://foo.localhost. (note the FQDN terminated with the root) should also be hard-coded to the loopback address.

In other words, if you don't like the hard-coded loopback address, you can simply terminate your hostname in the address bar with the root (period) and Firefox will resolve the hostname normally.

TLDR; http://dev.localhost (works as designed) http://dev.localhost. (works around the new hard-coded loopback address feature)

chris, thank you for telling us that. Could you please file a new bug on that?

Hi Henrik,

The steps to reproduce this are fairly simple.
There are authoritative nameservers here for the localhost TLD.
In the tree is a subdomain aaa.localhost.
In the aaa.localhost zonefile is an address record boot.aaa.localhost.

I configure boot.aaa.localhost as a virtual host inside nginx to listen on port 80 to use with GRUB network booting.
In the Firefox for Linux v98.0.1 64-bit address bar, if I type "http://boot.aaa.localhost" then Firefox will call out to the loopback address 127.0.0.1 unconditionally (as designed).

If instead, I type "http://boot.aaa.localhost." (by terminating the hostname with the root [period]) then Firefox will call out to the proper IP address found in DNS and not use the loopback IP of 127.0.0.1 as intended.

Best Regards,
-Chris

Hi Chris, thanks for the details! Would you mind to file a new bug for that and let us know about it's id (see comment 102)? Thanks in advance.

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+1] from comment #104)

Hi Chris, thanks for the details! Would you mind to file a new bug for that and let us know about it's id (see comment 102)? Thanks in advance.

I filed bug 1761414 for you. Thanks again for reporting it!

Hi Henrik, thanks for filing the new bug!