1542384 - Hangs on close when opening URL that cannot be resolved

Status: VERIFIED FIXED

(Core :: Networking, defect, P1)

Description

[martinheinrich]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1 Safari/605.1.15

Steps to reproduce:

• Cut internet connection at ADSL modem

• Open Firefox

• Type in URL e.g. netflix.com

• Close application while request times out

Actual results:

• Application window closes

• Process keeps running until time-out completes

• Being on macOS a new instance cannot be started unit process is "force quit" or timeout completes

Expected results:

• Application should close immediately

Comment 1

[martinheinrich]

Can be reliably reproduced with Firefox 66.0.2 on macOS 10.14.4

Can be reliably reproduced with Firefox 67.0b8 on macOS 10.14.4

Comment 2

[martinheinrich]

Can be reliably reproduced on a different machine

Comment 3

[Rares Doghi, Desktop QA]

Hi, we don't have the environment set up for this type of testing and I was unable to verify this issue but maybe our devs will have more luck with this issue, I'll set the component for it to Networking.

Comment 4

[martinheinrich]

Hi Rares

I looked into finding an easier way to reproduce the issue. I found some that may even shed some light on the cause.

One guess was that it times out on the DNS lookup and does not close until the timeout completes. I was able to create the same behavior by configuring an invalid DNS.

Steps to reproduce:

• In the System Preferences | Networking. Ensure there is only on active service.
• Overwrite the DNS of that service to 42.42.42.42
• Open Firefox
• Type in URL e.g. netflix.com
• Close application while request times out

Hope that helps.

Cheers
Martin

Comment 5

[Junior [inactive]]

Hello Reporter,
This hang is owning to unreliable DNS. Now it's 20 seconds.
https://searchfox.org/mozilla-central/rev/dd7e27f4a805e4115d0dbee70e1220b23b23c567/netwerk/dns/nsHostResolver.cpp#804
Could you please roughly check if it's around 20 seconds to close application completely?

Comment 6

[Valentin Gosu [:valentin]]

(In reply to Junior [:junior] from comment #5)

This hang is owning to unreliable DNS. Now it's 20 seconds.

We should make that into a pref and reduce it to 2-5 seconds anyway.

Comment 7

[martinheinrich]

(In reply to Junior [:junior] from comment #5)

Could you please roughly check if it's around 20 seconds to close application completely?

I can confirm it takes 20 sec after closing the application for the process to finish.

Comment 8

[martinheinrich]

(In reply to Valentin Gosu [:valentin] from comment #6)

We should make that into a pref and reduce it to 2-5 seconds anyway.

Just from using the application fixing the issue via the timeout duration may not create a clean close. E.g. using my laptop in the office I can work with a timeout of a second or two. That time would be not noticeable during close. Using my laptop on the bus tethered to my phone I would need something closer to fives second. That is a noticeable delay during close. Using both during a normal day would mean I'll use the higher setting all the time.

Having said that, 20 sec is a very long timeout. If that would be smaller, I would probably not have lodged this ticket. The same would be true for the other ticket I lodged at the same time (1542386).

Comment 9

[Junior [inactive]]

We should make that into a pref and reduce it to 2-5 seconds anyway.

I'm with you.
Timeout is for the xpcom-shutdown. Two seconds is enough.

P1 since I'm going to work on it.

Comment 10

[Junior [inactive]]

Attachment: Bug 1542384 - reduce timeout of shutdown resolver threads and make it prefable

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b4883506db14
reduce timeout of shutdown resolver threads and make it prefable r=valentin

Comment 12

[Andreea Pavel [:apavel]]

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

Comment 13

[Rares Doghi, Desktop QA]

Hi, I managed to reproduce this issue on Release 66.0.5 using the steps from Comment 4 but this issue no longer occurs on Firefox Beta 68.0b3 or Nightly 69. I will mark this issue accordingly.