1717253 - Many web pages open very slowly or not at all.

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect, P1)

Description

[Gary [:streetwolf52]]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

Install latest version of Nightly.

open up some web pages.

Actual results:

Pages mostly are very slow to open or don't open at all.

Expected results:

Web Pages should open quickly.

The last good build Is https://hg.mozilla.org/mozilla-central/rev/1cf3235975588162c28e4910fa1332f4907e7c47 which I am using at the moment.

Comment 1

[Ken Lui]

Workaround is to press ESC and reload the page.

Comment 2

[Eiichi]

In my case:
This issue ocuurs when enabling DNS over HTTPS.
This issue doesn't ocuur when setting network.trr.mode to 0.

Comment 3

[Kestrel]

Changing network.dns.force_waiting_https_rr to false avoids the issue with DoH enabled.

Regressed by Bug 1714506.

Comment 4

[Eiichi]

(In reply to Kestrel from comment #3)

Changing network.dns.force_waiting_https_rr to false avoids the issue with DoH enabled.

Thanks.
I have confirmed that changing network.dns.force_waiting_https_rr to false temporarily resolves the issue.

Comment 6

[Ken Lui]

force_waiting_https_rr

What does this setting is supposed to do? I can't find it on bugzilla, web search, https://hg.mozilla.org/releases/mozilla-beta/log?rev=force_waiting_https_rr, nor https://searchfox.org/mozilla-central/search?q=force_waiting_https_rr&path=.

Comment 8

[dolphinling]

(In reply to Ken Lui from comment #6)

force_waiting_https_rr

What does this setting is supposed to do? I can't find it on bugzilla, web search, https://hg.mozilla.org/releases/mozilla-beta/log?rev=force_waiting_https_rr, nor https://searchfox.org/mozilla-central/search?q=force_waiting_https_rr&path=.

It is a new pref added by the commit that regressed this. See https://hg.mozilla.org/mozilla-central/rev/adf68ff22830

Comment 9

[Kershaw Chang [:kershaw]]

Could you try to get a http log?
Please try to get two log: one for the website that can't load anymore and the other one for the slow loading.
Thanks.

Comment 10

[Ken Lui]

Attachment: nightlylog(klui).zip

Here is my log file. I reset the config network.dns.force_waiting_https_rr back to true, exited nightly, and relaunched. I used about:networking to enable logging; the environment variables didn't seem to work. This version included sync as a module to log but the HTTP Logging link describing Windows logging also suggested rotate:200 so I included it.

First site I went to was google.com and it had no delay. I then went to www.yahoo.com and slashdot.org. Both sites triggered the problem.

Comment 11

[Kershaw Chang [:kershaw]]

(In reply to Ken Lui from comment #10)

Created attachment 9228017 [details]
nightlylog(klui).zip

Here is my log file. I reset the config network.dns.force_waiting_https_rr back to true, exited nightly, and relaunched. I used about:networking to enable logging; the environment variables didn't seem to work. This version included sync as a module to log but the HTTP Logging link describing Windows logging also suggested rotate:200 so I included it.

First site I went to was google.com and it had no delay. I then went to www.yahoo.com and slashdot.org. Both sites triggered the problem.

Thanks for the log!

May I ask you to reproduce this again with the test build from this try link? I also put the download links below.
Windows x64: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Myi6ToWJSo-KkkERUZ9xWg/runs/0/artifacts/public/build/install/sea/target.installer.exe
Linux: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/R1lRtTiLTBuf53B7gA9kcA/runs/0/artifacts/public/build/target.tar.bz2
Mac: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/DhjfGordT3-3EbDKy9Um5g/runs/0/artifacts/public/build/target.dmg

Comment 12

[Ken Lui]

It seems to work.

I made sure network.dns.force_waiting_https_rr was set to true and enabled DoH and used Cloudflare (Default). My portable Nightly with the same setting and addons disabled triggered the issue, but since I have quite a few configs toggled/set I am not sure if my limited test could be considered conclusive.

Others who are interested in resolving this issue, please test as well.

Comment 13

[Eiichi]

I tested the test build for Mac.

1. I set config as below:

• network.dns.force_waiting_https_rr to true
• network.trr.mode to 3
• network.trr.uri to https://mozilla.cloudflare-dns.com/dns-query

2. I deleted DNS cache.

The test build seems to work fine as same as before.

Comment 14

[Kershaw Chang [:kershaw]]

Attachment: Bug 1717253 - Call ProcessPendingQ() after the waiting of HTTPS RR is done, r=#necko

Comment 15

[Kershaw Chang [:kershaw]]

Thanks for everyone's help!

Comment 16

[Arash]

I seem to also be afflicted by this issue in Nightly on Ubuntu 20.04. As I noted in bug 1717263, the pages do eventually load after tens of seconds of being 'Blocked' according to the request timings in the developer tools. A 40 second block time is not uncommon.

As Kestrel suggested, changing network.dns.force_waiting_https_rr to false does avoid the issue.

I reset network.dns.force_waiting_https_rr to true, enabled DoH and using the build kershaw linked, I generated a log from visiting two sites: www.washingtonpost.com and www.nytimes.com. The log is too big to attach, but it's on my server:
https://ara.sh/private/firefox-bugzilla/2021-06-21-091622-log-from-test-build-arash.zip

Note: I didn't experience the super long block time with this build.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/29139aa4ec66
Call ProcessPendingQ() after the waiting of HTTPS RR is done, r=necko-reviewers,dragana

Comment 18

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/29139aa4ec66

Comment 20

[mmis1000]

It seems I still get this randomly happened. A profile I just captured has a 20 sec delay in the first request for some reason.

The profile

The request stucks in waiting for socket channel for 20 secs. And It correspond to a quid timeout event in socket thread of main process. Is this a separate issue and need to open another ticket for it?