As pointed out in phabricator it seems nsHostResolver::InitLoopbackRecord calls GetAddrInfo which is not OK, as that:

1. Defeats the purpose of having a loopback record if we still use the system resolver to get it
2. Blocks the calling thread until the record is resolved, which is even worse.

Instead we should construct and addrInfo directly like here

The test was using network.dns.localDomains to check that we don't
call into the platform DNS resolver when the network.dns.disabled pref
was set - but since the localDomains pref rewrites hostnames to localhost
and we now don't call into GetAddrInfo for local domains, the test
failed.
I changed it so it uses the NativeDNSResolverOverride to register an IP for
foo.bar instead of relying on localDOmains.

Depends on D94726

https://hg.mozilla.org/mozilla-central/rev/376f50682766
https://hg.mozilla.org/mozilla-central/rev/6df4ac02675f

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

This bugfix caused a side issue on my system (linux). I use a service (monit) that has an interface at http://localhost:2812 Firefox was unable to open this page. Other browsers on my system worked: palemoon, opera, chromium, falkon, lynx, netsurf (the last two connected to the server but were unable to display the final page due to their limited implementations). Others to have issues were links, dillo, and w3mmee

Since palemoon worked, I bissected FF. mozregression lead me to 84.0a on 2020-10-26 (more than a year ago at the time of this writing, using FF 95.0.1 on 2022-04-05). It could not bissect further because the changes were too old, but by reading the pushlog for that day I identified this bug and changeset as the most probable cause for the problem I had.

Finally by analyzing the logs of the service I found the service was refusing requests from 127.0.0.1 while it accepted them from ::1. I checked /etc/hosts which was:

::1             localhost
#127.0.0.1       localhost # this line was commented

By uncommenting the second line, it started to work.

The strange part is that other services on the machine: cups http://localhost:631 and syncthing http://localhost:8384 worked without a problem with Firefox, only the service at port 2812 did not open.

While my system was not well configured, and correcting the configuration made it work, I still believe this could be worth of discussion at Firefox, because other modern browsers simply queried 127.0.0.1 and ::1 successively until success, while FF after this revision only queried 127.0.0.1 and failed.

Here is the discussion I had with monit maintainer that helped identify the problem. https://bitbucket.org/tildeslash/monit/issues/1024/localhost-2812-on-firefox-84-the

(In reply to Jérôme Borme from comment #6)

So, the problem here is with the listening service.
If it was only listening on IPv6, then connecting to IPv4 should have failed, and Firefox would have retried using IPv6.
But instead, the service was listening on both, but rejected requests over IPv4. The only reason it worked before was because the misconfiguration was also reflected in the DNS response to getaddrinfo.