1580781 - Firefox starts up slow when the local hostname cant be resolved

Status: UNCONFIRMED

(Core :: Networking: DNS, defect, P2)

Description

[Titan Strix]

Attachment: simplescreenrecorder-2019-09-12_02.46.47.mp4

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36

Steps to reproduce:

Fedora comes with this setting in its /etc/hosts :
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
I always had problem with Firefox in fedora. anything than Firefox is great in this distro and I like its pre-configs. Because Firefox is my favorite browser, I decided to migrate to Arch Linux where Firefox works well. But why it works well? I didn't know till an accident. I just pasted some of fedora configs to Arch Linux and one of theme was /etc/resolv.conf. firefox started to take 40-60 seconds to be opened from clicking time. Well I returned back original config and the problem gone. What was original config?
127.0.0.1 localhost
::1 localhost
127.0.1.1 STRIX.localdomain STRIX
STRIX is my hostname.
I talked with guys and they said it's a bug. They said GUI should never wait for DNS to be solved. I have this problem for two years and today I found it's a bug.

Actual results:

When setting /etc/hosts to:
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain
Firefox take 40-60 seconds to be opened. when setting it to :
127.0.0.1 localhost
::1 localhost
127.0.1.1 STRIX.localdomain STRIX
it starts immediately. As you can see in attached video.

Expected results:

The GUI should not wait for DNS even if this were a failure in that section. Like what Chromium does. It should starts immediately. It's really boring waiting 1 minute on i7-8700k system to Firefox be opened.

Comment 1

[Virginia (please send need info request to Brindusa Tot)]

Hi Titan Strix,

Thanks for reporting this bug.

Unfortunately, I'm unable to test this on my end since I don't have Fedora on my Linux machine but as a starting point, I'll add a product and component so the dev team can take a look at this ticket.

Could you please re-upload the screen recording? I tried to open it but the video is blank.

Regards,

Comment 2

[Titan Strix]

Attachment: simplescreenrecorder-2019-09-12_02.46.47.mp4

reconverted and reuploaded

Comment 3

[Titan Strix]

https://anonymousfiles.io/AatDpL8A/

Comment 4

[Titan Strix]

https://anonymousfiles.io/AatDpL8A/
Video of problem

Comment 5

[Martin Stránský [:stransky] (ni? me)]

I believe it's rather networking problem that the Widget/Gtk one.

Comment 6

[Andy Grover [:grover]]

Valentin what do you think?

Comment 7

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

Hi Martin, Thanks a lot for reporting this - I really hope we can figure out what's going on here.

I am unable to reproduce this on Ubuntu. in comment 0 you also mention /etc/resolv.conf - could you also paste the contents of that?
Also, just in case, are you using Wayland or XOrg?

Comment 8

[Rares Vernica]

I'm able to reproduce this in on Firefox 78.0.2 and Fedora 32. Adding the extra line in /etc/hosts solves the problem.

Comment 9

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

Redirect a needinfo that is pending on an inactive user to the triage owner.
:dragana, since the bug has high priority and recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 10

[Berend De Schouwer]

If it helps, Thunderbird 91 appears to be doing the same thing as Firefox 101.

You end up with a zombie process: Z firefox [defunct]. The main process then waits for a timeout. So it looks like a missing waitpid()/sigchld.

I think resolv.conf only matters if your pc/laptop is in DNS, which it might not be.

Comment 11

[xad6]

It looks to me like this is related to bug 1448783, which was determined to be due to nsProfileLock::LockWithSymlink() trying to synchronously resolve the system's hostname.

I can reproduce this if I remove the entry for my hostname from /etc/hosts, and try to start Firefox while disconnected from the internet. What's going on there is that my OS can't resolve my hostname via the hosts file, so it attempts to resolve it using DNS. If I'm offline, DNS won't work so we have to wait for the DNS query to timeout. Confirmed this using wireshark: with my hostname in the hosts file, there are no DNS queries for my hostname upon firefox startup; with my hostname removed from the hosts file, there are DNS queries for my hostname, which timeout if I'm offline.

Tested this on Firefox 107.0 on Void Linux, Firefox ESR 78.14.0 on Kali Linux, and Firefox ESR 102.4.0 on Alpine Linux. Was able to reproduce the issue on all of these setups by removing my hostname from the /etc/hosts file and disconnecting myself from the network. I assume you could do the same on pretty much any distro and get the same results. I've experienced the same issue with Thunderbird as well.