1793335 - Cannot load any site for a long time after restarting the browser when using PAC and DoH together.

Status: NEW

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

Description

[y3110wp00k33]

Steps to reproduce:

Firefox Dev Edition 106.0b6 64-bit on Windows 10.
UA: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:106.0) Gecko/20100101 Firefox/106.0

Clean new profile.
Set this prefs:

user_pref("network.proxy.autoconfig_url", "https://antizapret.prostovpn.org/proxy.pac");
user_pref("network.proxy.type", 2);
user_pref("network.trr.mode", 3);
user_pref("network.trr.uri", "https://mozilla.cloudflare-dns.com/dns-query"); // can use any DoH svc, it doesn't matter

Contents of PAC file is here: https://paste2.org/1y4w01Ck

Restart Firefox.

Actual results:

Can't load any site right after restart as if there is no internet connection. This goes on for up to a half of minute or more.

Expected results:

Sites should open after restarting the browser without such a huge delay.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Dragana Damjanovic [:dragana]]

Have you observed this issue earlier or is it a new issue in Firefox 106?

Comment 3

[y3110wp00k33]

Earlier. Just tested it on 91.13.0ESR.
Maybe the problem exists in earlier versions as well.

Comment 4

[Kershaw Chang [:kershaw]]

Could you try to record a http log?
It'd be interesting to see what happens during startup.
Please also add proxy:5 to MOZ_LOG. Thanks.

Comment 5

[y3110wp00k33]

Applied this:

set MOZ_LOG=timestamp,rotate:1000,nsHttp:5,cache2:5,nsSocketTransport:5,nsHostResolver:5,cookie:5,proxy:5
set MOZ_LOG_FILE=%CD%\moz.log

launched it with an empty profile containing user.js with proxy and trr parameters, waited for the mozilla start pages to open, then closed FF.
So here are the logs: https://envs.sh/Qzn.zip

Also, I found that if proxy.pac is not downloaded from the URL, but loaded locally from the disk, this problem does not exist.

So, use this when trying to reproduce:

user_pref("network.proxy.autoconfig_url", "https://envs.sh/QzT.pac");

Comment 6

[Kershaw Chang [:kershaw]]

Thanks for the log.
It shows that the PAC request is failed after the long timeout of trr mode 3 and all other http requests are blocked by the PAC one.
Maybe we should also disable TRR for PAC request.
Valentin, what do you think?

Comment 7

[y3110wp00k33]

This is not very good, because it may not be possible to reach the PAC except through TRR (domain blocking by the provider, for example).

On the other hand, if the PAC file is on the local network - TRR will never resolve local domain at all.

Maybe just disable trr mode 3 (force fallback) for PAC URL? With mode 2 all works fine.

Comment 8

[Valentin Gosu [:valentin]]

(In reply to Kershaw Chang [:kershaw] from comment #6)

Maybe we should also disable TRR for PAC request.
Valentin, what do you think?

I thought you meant DNS resolves triggered by the PAC script here which already don't use TRR, but you mean we should disable TRR for the PAC script channel here right?

I would have expected that TRR requests would not be resolved using the PAC script until the PAC is actually installed - but that's apparently not the case. There's clearly another bug here, since it works when you initially set the PAC script, but not after restart when it's already set?

In any case, I think a temporary fix might be if global TRRMode==3 then set PAC channel TRRMode to be TRR_FIRST_MODE.

Comment 9

[y3110wp00k33]

since it works when you initially set the PAC script, but not after restart when it's already set?

Yes it is

Comment 10

[BMO Automation]

Moving bug to Core/Networking: Proxy.