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

Steps to reproduce:

Version: Tried 104 and 105
OS: Windows 10

TL;DR: How can the timeout be reduced or a proxy be avoided if it isn't available and DIRECT should be used?

At work the proxy settings of Firefox are set by the company and greyed out.
It is set to use the system settings.

The system setting is using a PAC file which is fetched via http.

That PAC file can be boiled down to the following (the previous part has no influence to the problem):
PROXY 127.0.0.1:8888; DIRECT

The company set it this way to allow developers to use Fiddler for network analysis.

But the problem is that Firefox is very slow if Fiddler isn't running and therefore port 8888 isn't listening/available. Every call to any site takes several seconds.

If Fiddler is running Firefox is back to the usual speed.

Other browser like Chrome and Edge don't have this issue and are fast independent of Fiddler running.

Is this a bug in Firefox? I have found https://bugzilla.mozilla.org/show_bug.cgi?id=1549678 which goes in a simular direction.
However, the delay is bigger than described (not just 1-2 seconds).

Are there maybe settings that could positively influence this?
I am looking for something like this:

• Try the proxy only once with a given timeout. If it's not available avoid it. I believed Firefox already does this (caching), or not?
• If there is no caching possible and the check if for every call it would be good to somehow define that a proxy should be avoided.
• If that's not possible it would be good to reduce the timeout for the proxy check.

I cannot modify the PAC file and also not change the default Firefox proxy setting.
But seemingly I can change other about:config settings.

I believed that network.proxy.failover_timeout could help. But network.proxy.type needs to be set to 2 for it to work but is set to 5 by the company.

Thank you very much in advance for any help & hints!

Actual results:

Websites take multiple seconds to load without Fiddler (proxy) running.

Expected results:

Like Chrome & Edge it should avoid the not running proxy and use the direct route.

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.

(In reply to trash22 from comment #0)

I believed that network.proxy.failover_timeout could help. But network.proxy.type needs to be set to 2 for it to work but is set to 5 by the company.

It may be that the timeout is also set by the company policy
Technically, the connection to the proxy should fail quickly, so I'm not exactly sure why the long timeout.

This seems to be the exact same problem as bug 1549678, but there the failing proxy is not local, so it probably takes longer.
I think I'll add a pref to bug 1549678, and you can confirm if that fixes the problem. Then we can use this bug to devise a better fix for this.

(In reply to Valentin Gosu [:valentin] (he/him) from comment #2)

(In reply to trash22 from comment #0)

I believed that network.proxy.failover_timeout could help. But network.proxy.type needs to be set to 2 for it to work but is set to 5 by the company.

It may be that the timeout is also set by the company policy
Technically, the connection to the proxy should fail quickly, so I'm not exactly sure why the long timeout.

This seems to be the exact same problem as bug 1549678, but there the failing proxy is not local, so it probably takes longer.
I think I'll add a pref to bug 1549678, and you can confirm if that fixes the problem. Then we can use this bug to devise a better fix for this.

Thank you! I will test it with the new setting.
I am assuming I have to wait for the next nightly build or should I do something else?
After validating it I will come back to you how it behaves.

After bug 1549678 is closed, it should be in the next nightly.

I can confirm. It works with the new setting (set to false).
Thanks!

Thanks for confirming.
I think the fix for bug 1494364 might not have been optimal, especially for use cases like this where proxies are expected to be offline.
According to this comment:

  // NOTE: The classic codebase would increase the timeout value
  //       incrementally each time a subsequent failure occurred.
  //       We could do the same, but it would require that we not
  //       remove proxy entries in IsProxyDisabled or otherwise
  //       change the way we are recording disabled proxies.
  //       Simpler is probably better for now, and at least the
  //       user can tune the timeout setting via preferences.

We should switch to doubling the timeout value from 10 seconds to mFailedProxyTimeout with every failure.
We might also consider to retry all proxies if the channel is a force-refresh of the page.
For that matter, we should look into how Chrome is handling failed proxies here

Just as an additional info. The official documentation of Mozilla describes how it is intended to behave:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_PAC_file

If there are multiple semicolon-separated settings, the left-most setting will be used, until Firefox fails to establish the connection to the proxy. In that case, the next value will be used, etc.

The browser will automatically retry a previously unresponsive proxy after 30 minutes. Additional attempts will continue beginning at one hour, always adding 30 minutes to the elapsed time between attempts.

If all proxies are down, and there was no DIRECT option specified, the browser will ask if proxies should be temporarily ignored, and direct connections attempted. After 20 minutes, the browser will ask if proxies should be retried, asking again after an additional 40 minutes. Queries will continue, always adding 20 minutes to the elapsed time between queries.

Seemingly the change of the other ticket is a niche requirement and shouldn't be the default (?).
But that is just my interpretation. Or the above documentation is not correct.