User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:63.0) Gecko/20100101 Firefox/63.0 Steps to reproduce: When using network.trr.mode;3 with a system-wide HTTP proxy, HTTP URLs do not connect in Firefox. HTTPS URLs work fine. Actual results: HTTP requests hang on connecting to the domain name. Expected results: Web page should open normally.

I couldn't reproduce this issue on Osx 10.14 and Ubuntu 16.04 (Nightly 65 2018-11-21 and Release 63.0.3), but using a Nord VPN, not a system wide proxy (cannot use system wide proxies) and I would guess that would be one of the reasons. I'm not particularly sure how network.trr.mode 3 should behave in practice, therefore in order to move forward with this bug, let's triage it to core::networking.

Hello Kurian, We need log information to analysis what happened. Could you attach the log and append the MOZ_LOG environment variable with proxy:5? See instructions here: https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

trr mode 3 is trr only, we do not recommend to use this mode. I am interested in seeing the log anyway and fixing the issue.

Will post a log when I have access to the system after the holidays.

The HTTP domain visited is http://www.kathampy.com/ The system-wide proxy uses a PAC file.

I saw this line D/proxy pac not available, use DIRECT which indicates that we failed to load pac file Two questions: (a) In your environment, do you need the proxy for visit http://www.kathampy.com ? (b) Is it the same result by setting the pac in firefox? We might need the startup logging (or some hacking about:config), but let me figure out if we have enough logging. Thanks!

All outbound ports need the proxy. However port 443 is also allowed through the default gateway, so it must be falling back to this for HTTPS URLs. I'll try setting the PAC in Firefox tomorrow. The PAC URL has a local hostname which needs the local DNS server. If the PAC is downloaded by Firefox and not the system, the resolution would fail. Perhaps TRR mode 3 should make an exception for resolving the PAC locally.

(In reply to Kurian Thampy from comment #7) > The PAC URL has a local > hostname which needs the local DNS server. If the PAC is downloaded by > Firefox and not the system, the resolution would fail. Perhaps TRR mode 3 > should make an exception for resolving the PAC locally. Firefox has no way of automatically knowing which domains should be resolved with a local domain. TRR mode 3 is definitely not the right choice for this scenario.

(In reply to Valentin Gosu [:valentin] (PTO until 7th of Jan) from comment #8) > (In reply to Kurian Thampy from comment #7) > > The PAC URL has a local > > hostname which needs the local DNS server. If the PAC is downloaded by > > Firefox and not the system, the resolution would fail. Perhaps TRR mode 3 > > should make an exception for resolving the PAC locally. > > Firefox has no way of automatically knowing which domains should be resolved > with a local domain. TRR mode 3 is definitely not the right choice for this > scenario. No. But the error reporting here is poor as well, IMO. PAC is vital. If we can't resolve the host name where the PAC is served from, we should show an error page explaining it.

(In reply to Honza Bambas (:mayhemer) from comment #9) > PAC is vital. If > we can't resolve the host name where the PAC is served from, we should show > an error page explaining it. Maybe P3 if PAC is important to us? I was thinking we could specifically make PAC load with TRR disabled, but that would really mess with our definition of TRR-only mode :)

We could user TRR-first for PAC. But get consent from the user first before falling back. We may also simply have a host name whitelist for fallback. When the proxy setting is changed, we may add some "test the PAC" functionality (as e.g. most mail clients do when you setup an email account access) by doing the detect-portal request, maybe?

(In reply to Honza Bambas (:mayhemer) from comment #11) > We could user TRR-first for PAC. But get consent from the user first before > falling back. Exposing the UI would be a pain :) > We may also simply have a host name whitelist for fallback. This seems to be needed more and more. Blocking on bug 1450893 > When the proxy setting is changed, we may add some "test the PAC" > functionality (as e.g. most mail clients do when you setup an email account > access) by doing the detect-portal request, maybe? That would be really nice to have.