Filing this bug as a follow-up to what chris has been found on bug 1220810 comment 103 which handles cases when localhost is specified with a trailing dot.

Here more details:

(In reply to chris from bug 1220810 comment #103)

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

This seems to be a sign of a more generic hostname-parsing problem: Hostnames are treated as strings, but they should not be.

Reason: Hostnames (and also any other DNS names) are defined as sequence of "labels" which are dot-separated, not strings.

If the names are parsed correctly by that definition "localhost" and "localhost." would parse to list of labels ['localhost', (unspecified origin)] vs. ['localhost', root_label]. Traditionally the "unspecified origin" triggers "domain search logic" in stub resolver (see "search" in man resolv.conf), and the search list is not used when the origin is specified (the trailing dot in hostname "presentation" format).

(In reply to Petr Špaček from comment #1)

This seems to be a sign of a more generic hostname-parsing problem: Hostnames are treated as strings, but they should not be.

The stub resolver APIs implemented by operating systems take strings. The browser isn't really concerned whether you want to resolve example or example. so handling them as anything but strings would not help much.
However, localhost is a special case, since we call the stub resolver for it. So a targeted fix is in order here.

Where this would help is in various caches, exception lists, etc - where we say let's exclude example.com from using HTTP/2, but loading example.com. would bypass that check. However, that is out of scope of this bug.

https://hg.mozilla.org/mozilla-central/rev/3870e3f7a52a