1207798 - Proxy: Firefox fallback to regular connection when proxy is not available

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[wonder.mice]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.99 Safari/537.36

Steps to reproduce:

Install Firefox 41.0 (it was the case also with 40.3).

1. Set proxy settings to "Automatic Proxy configuration URL"
2. Set proxy configuration URL to "http://proxy.causaldomain.com/proxy.pac" (or any other unreachable URL I guess)
3. Save changes, try to access any web site



Actual results:

Firefox wait for a long time (trying to get proxy settings, I guess).
Then it loads the page that was requested. It also will load any other page very quickly.
So, proxy is not used at all (bypassed).
You can go to https://www.whatismyip.com (or similar) and confirm that IP address is yours (not from proxy).


Expected results:

Firefox should show an error that it failed to get proxy configuration.
It shouldn't even try to access requested web page bypassing the proxy.

Comment 1

[:Gijs (out for now; he/him)]

I can reproduce. This seems odd. Very old bug though - I see the same behaviour on e.g. 29. Steve, is this by design?

Comment 2

[Steve Workman [:sworkman] (INACTIVE)]

Pat, is falling back to a regular connection ok if the pac file isn't found?

Comment 3

[wonder.mice]

> is falling back to a regular connection ok

Of course it's not OK.
HTTPS proxy could be used to securely transfer unencrypted traffic (HTTP) to a safer location (proxy).
In such case attacker can block packets preventing Firefox from getting proxy configuration.
After that all HTTP request will go plaintext to the destination and user will not know about that.

Comment 4

[wonder.mice]

This one even better. If proxy configuration URL set to something like that (note non-standard port):
https://proxy-us.causaldomain.com:465/proxy.pac
Firefox will silently ignore proxy settings and just work over regular connection. Because:
"This address uses a network port which is normally used for purposes other than Web browsing. Firefox has canceled the request for your protection."

Comment 5

[Patrick McManus [:mcmanus]]

it has always been like this (from before my time) and it is implemented as pretty clearly intended from the code. So its not an implementation bug or regression somewhere along the line..

We should still consider if its doing the right thing before wontfixing, of course.

The primary issue is that this is used to make mobility work well - i.e. home to office transitions. Its common for someone to have a proxy configured thats only available on the office network and just leave that config in place when they go away from the office - that pattern is widely used and if we make this hard fail, we'll break those users.

From a security pov, there is of course some value in the value of the route (be it over tls, a vpn, or just a preferred link)- but the real evaluation of security comes down to the scheme of the transaction which is not impacted by the proxy choice which is why this has not been a hard requirement. Of course for much of that history we couldn't proxy over https but I think that's just a subset of the interesting cases anyhow.

Daniel is actually working a bug where this failover is too slow (almost the opposite of this bug) so I think he is best positioned to evaluate what a change would mean. The data I would be most interested in is the behavior ie, edge, and chrome..

Comment 6

[:Gijs (out for now; he/him)]

We could potentially add a pref for those who want to strongly prefer their proxy routing, and prompt in the frontend when this kind of fallback happens, defaulting to a one-time prompt (checked box "do not ask me again" type thing) ?

Comment 7

[Daniel Stenberg [:bagder]]

I cannot reproduce this behavior if I point it to a PAC URL that works and then then PAC returns a proxy that is causing problems (inaccessible or just refusing access).

I've had several users report our _failure_ to swiftly give up the configured proxy and switch to DIRECT as a problem, and from my testing it seemed that both Internet Explorer and Chrome switches to DIRECT easier and faster and that's what these users I've spoken to have wanted for Firefox too.

Sort of amusing that what is reported here is almost exactly what I've been trying to make happen in bug 1121800. 

These persons are as Patrick says using a proxy/PAC in one network situation (work for example) and then they bring their running Firefox into a new network where the proxy/PAC-URL is no longer accessible but they still want their Firefox to work. And we don't provide any way for them to specify that they only want the proxy in one of these networks but not the other(s).

So maybe we need some UI/config boolean for this...

Comment 8

[Patrick McManus [:mcmanus]]

I'm going to move this over to steve's team for them to figure out the desired behavior.. If we end up offering some kind of vpn mode, it could conceivably be more important.

I also don't think this needs to be security restricted. dan?

Comment 9

[Steve Workman [:sworkman] (INACTIVE)]

(In reply to Patrick McManus [:mcmanus] from comment #8)
> I'm going to move this over to steve's team for them to figure out the
> desired behavior.. If we end up offering some kind of vpn mode, it could
> conceivably be more important.

Thanks for looking into this Pat and Daniel (:bagder). I'll add this to the list of items for security UX. I'm thinking that we'll need a combination of UX to allow the user to decide what to do and fast fallback for performance. It seems like Daniel is already working on the latter part. And the former we'll prob want something like this for a vpn-like mode, yup.

Comment 10

[wonder.mice]

How curious, I didn't though that somebody could use proxy just to get "some" internet connectivity. I do agree that it's a valid use case though. Usually I hate solutions that require adding one more checkbox or a dialog, but don't see other options here. User must tell us somehow why proxy is in use and what the expected behavior is.

After thinking about that a bit, it looks like it make sense to have a list of possible ways to connect to internet. If regular connection is included in that list, then FF is allowed to fallback to it. As a bonus users will be able to specify several proxies there and FF will be able to choose the one that currently works. But I guess it can be too complicated for a regular user.


> I also don't think this needs to be security restricted. dan?
Well, that could be used as an attack vector to tamper with user traffic when proxy is used for security purposes.

Comment 11

[Daniel Veditz [:dveditz]]

(In reply to wonder.mice from comment #10)
> > I also don't think this needs to be security restricted. dan?
> Well, that could be used as an attack vector to tamper with user traffic
> when proxy is used for security purposes.

There are few enough people (percentage-wise) using PAC that it's more helpful to publicize this as a problem to watch out for than the bad-guys it would give ideas to.

I'm not sure what a "fix" looks like here given some people do legitimately switch from using a proxy and not. We could always nag the user when it switches-- that's an option in the VPN I use, for example. Less than a nag, maybe we could put an icon for proxies in the URL bar, and change it to a "broken" version when PAC is configured but not reachable. Don't know what a good user experience would be here.

It's also hard because sometimes the lack of proxying is not a security issue at all so we don't want to over-emphasize it. For example, in the situations Daniel is dealing with in bug 1121800 if you can't reach the proxy because you've gone home you simply can't access your sensitive work sites--no harm done.

NOTE: I'm a bit confused by what this bug is actually complaining about. The summary says the _proxy_ is not reachable but the first few comments by the reporter describe the Proxy Auto Config URL not being reachable. Daniel seemed to describe a case (from the other bug) where the PAC was reachable (or cached) but the proxy configured by it was not. We could very well want different behaviors in those three cases. PAC is usually a "work thing" -- if it's set up then you generally need it to function to reach some or all of the network for your work. If you can't load it and you needed it then the failure mode is usually pretty safe. Ditto a proxy set by a PAC. Setting an explicit proxy, on the other hand, can lead to bad consequences depending on why you're using the proxy (for example, Tor) and we shouldn't fall back to direct in that case.

Comment 12

[wonder.mice]

> I'm a bit confused by what this bug is actually complaining about.
Formally, the original issue was about the case when PAC URL no being reachable.
However,

Comment 13

[wonder.mice]

> I'm a bit confused by what this bug is actually complaining about.
Formally, the original issue was about the case when PAC URL no being reachable. However, the scope of the issue is wider. There are some cases when proxy is used for security purposes. In such cases, it's not acceptable to fallback to regular connection silently (in all cases: when PAC URL is not reachable, when proxy itself is not reachable, when proxy cert is invalid, when PAC URL uses blacklisted port, etc.). I renamed a bug to make it a bit more clear :)

> Setting an explicit proxy, on the other hand, can lead to bad consequences
Unfortunately, HTTPS proxy can be configured only by PAC right now.
And it's the only (correct me if I'm wrong) proxy type that does encryption and doesn't sends proxy-auth in plain text.

> Don't know what a good user experience would be here.
Suggestion.

Available connectivity methods:
+----------------------------+-+
| [v] Regular connection     |O|
| [ ] Proxy 1                | |
| [v] Proxy 2                | |
| [ ] Proxy 3                | |
+----------------------------+-+
              [ Add ] [ Remove ]

When [ Add ] is clicked current proxy configuration dialog is invoked. If Regular connection checkbox is set, FF is allowed to fallback to regular connection. If not, only chosen proxies could be used. In other words, FF will cycle throw the list and try each enabled method. People that want just "some connectivity" can set all checkboxes and enable all methods. People who expect security could disable Regular Connection and enable only one Proxy that they trust.

Comment 14

[Masatoshi Kimura [:emk]]

How about making the proxy option non-exclusive, like Internet Explorer?

Comment 15

[Tanvi Vyas[:tanvi]]

As others have said, it seems like you just need a checkbox that is unchecked by default in about:Preferences->Advanced->Network->Connection Settings that says something like:
"If the proxy is unavailable, do not connect to the internet"

with a Learn More link.

If we want to make an even better UX, we can tell the user that the proxy is not available in the error page and give them a link to change their proxy settings that goes directly to the Connection Settings.

Given this is the way Firefox has worked forever and given that we don't have a Firefox VPN yet, I think this is low priority as for as UX requests go.

Comment 17

[Anon Y. Mous]

Dunno if all of you folks noticed, this bug affects not only unavailable PAC URL, but ANY proxy setting. If PAC exists but proxy it's embedded function returns does not accept conections, Firefox still tries to bypass proxy via direct connection. Even if PAC does NOT return 'DIRECT' statement as a fallback. Moreover, it does also when a proxy is distinctly specified by 'manual setting' in network options!
I've faced with this misbehavior when my NAS box (which also provides TOR proxy for my whole LAN) was accidently shut down. And there was a great surprise to see the loaded page after a single click on 'try again' button. I was surprised even more when discovered that neither manual configuration nor using PAC could not solve the issue. After all I've studied all variables in about:config with 'proxy' or 'networking' in its name, but found nothing appropriate. Google could not help too. So I've decided to open the bug report(https://bugzilla.mozilla.org/show_bug.cgi?id=1219052) which was closed at once as a duplicate of this one. But here I can see the discussion only on the single specific case, not on the problem in general. That's why I've voted for this bug and wrote this comment to explain my reasons.
I belive this issue affects a lot of people. Those who used to use Firefox in restricted configuration like various kiosks. Who use the so-called 'black-hole proxying'. People using some unfair provider or other non-trusted networks like wifi hotspots. And finaly it affects people who live under the tyrannical power like China, Russia, etc. where their network activity is tracked and the leakage could cost them their freedom and even their lives. In fact, I also do live in the region occupied by foreign troops who forced all local providers to block wide range of resources and to collect information about their users attempts to visit prohibited resources. 
So I ask developers to give a bit more attention to this problem. Please, please, please, make any simple workaround ASAP. The single option 'network.proxy.fallback_to_direct' (with 'true' by default) would be quite enough for most cases.
Thank you very much.

Comment 18

[tmkk]

Agree to comment 17. The problem occurs after upgrading to 44.0a2.

On Firefox 44.0a2, build ID: 20151104004053

Steps to reproduce:
1) Set proxy server to localhost:1000 (or other unavailable address/port)
2) Open address http://edition.cnn.com/
3) Firefox shows an error page
4) Hit "Try Again"

Actual results:
Firefox connects to http://edition.cnn.com/ directly without using a proxy

Expected results:
Firefox should continue to show the error page

Comment 19

[Alice0775 White]

[Tracking Requested - why for this release]: a hole of proxy, unexpectedly connected to network when using proxy.


Regression window:

1st regression(crash when retry)
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=958e4293006dff60f8cb703335be335e9fc52ab6&tochange=9d24051f4449

Regressed by:  Bug 1121800 - when all proxies fail try DIRECT, r=mcmanus


2nd regression(not crash, but fallbacked to direct connect when retry)
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=52f7eb6257e0769cd575c2e946360fdc3f29be26&tochange=a62a3c113e40


Regressed by: a62a3c113e40	Daniel Stenberg — Bug 1214200: avoid double NS_RELEASE(), r=mcmanus

Comment 21

[Daniel Stenberg [:bagder]]

So there are two camps of users:

A) the users who set a proxy in one network and then move to another with the now inaccessible proxy still set and they then end up in a situation where they have to manually disable/enable the proxy when switching between networks. Something apparently some other browsers don't need to do.

B) the other camp is users who NEVER want to side-step the proxy and if the proxy is inaccessible it is so for a reason and we should NOT attempt to go directly as that could leak information and what not.

I can't see how we can please both camps without addition an option somewhere.

Comment 22

[Alice0775 White]

In the case of A),
I think that
User can be set proxycfg.pac like following.
It can be fallbacked to "DIRECT" when it is failed to "PROXY foo" and "PROXY bar".

function FindProxyForURL(url, host) {
if (url == "something") {
  return "PROXY foo; PROXY bar; DIRECT";
}

....

}

I do not understand why the original Bug 1121800 is valid.

Comment 23

[Alice0775 White]

So, I think Bug 1121800 should be backed out.

Comment 24

[Jesse Ruderman]

Like erahm's setup in bug 1121800 comment 32, DOMFuzz relies on an invalid proxy to avoid hitting the network and tripping the MOZ_DISABLE_NONLOCAL_CONNECTIONS crash. So I'd also like a fix, or an easier workaround than running a real proxy server on all of my machines.

Comment 25

[Patrick McManus [:mcmanus]]

(In reply to Jesse Ruderman from comment #24)
> Like erahm's setup in bug 1121800 comment 32, DOMFuzz relies on an invalid
> proxy to avoid hitting the network and tripping the
> MOZ_DISABLE_NONLOCAL_CONNECTIONS crash. So I'd also like a fix, or an easier
> workaround than running a real proxy server on all of my machines.

can you set a pref? We can certainly add a gecko pref right now and let the front end team debate if they want to expose it..

Comment 26

[Jesse Ruderman]

Yes, I'd be happy with a pref.

Comment 27

[Patrick McManus [:mcmanus]]

(In reply to Jesse Ruderman from comment #26)
> Yes, I'd be happy with a pref.

daniel, can you do this? (don't change default behavior)

Comment 28

[Daniel Stenberg [:bagder]]

Attachment: 0001-bug-1207798-add-pref-to-toggle-proxy-behavior-when-i.patch

This patch introduces the pref "network.proxy.failover_DIRECT" which is true by default. Setting it to false will make it _not_ try DIRECT when the proxies fail.

Comment 29

[Patrick McManus [:mcmanus]]

Comment on attachment 8685530 [details] [diff] [review]
0001-bug-1207798-add-pref-to-toggle-proxy-behavior-when-i.patch

Review of attachment 8685530 [details] [diff] [review]:
-----------------------------------------------------------------

::: modules/libpref/init/all.js
@@ +1822,5 @@
>  pref("network.proxy.socks_version",         5);
>  pref("network.proxy.socks_remote_dns",      false);
>  pref("network.proxy.proxy_over_tls",        true);
>  pref("network.proxy.no_proxies_on",         "localhost, 127.0.0.1");
> +pref("network.proxy.failover_DIRECT",       true);

a comment here is a good place to document it.

and that's one ugly name. Feel free to update it before checking in :)

::: netwerk/base/nsProtocolProxyService.cpp
@@ +1420,5 @@
> +        // directly or via system settings
> +        if (mProxyConfig != PROXYCONFIG_PAC &&
> +            mProxyConfig != PROXYCONFIG_WPAD &&
> +            mProxyConfig != PROXYCONFIG_SYSTEM)
> +            return NS_ERROR_NOT_AVAILABLE;

braces

@@ +2044,5 @@
> +                nsProxyInfo *reject = iter;
> +
> +                iter = iter->mNext;
> +                if (last)
> +                    last->mNext = iter;

as long as we're moving this around fix the bracing

Comment 31

[Daniel Stenberg [:bagder]]

Attachment: v2-0001-bug-1207798-add-pref-to-toggle-proxy-behavior-whe.patch

The try servers are unfortunately having a very hard time right now so it isn't easy to figure out things: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b1ab7b594e66

I could not detect a problem related to this patch there.

The pref to alter this behavior is called "network.proxy.use_direct_on_fail" in this patch, and it defaults to 'true'.

Comment 32

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/410f33dfbc89

Comment 33

[[e-mail]]

why does it default to 'true'?
Is there any evidence that more people can benefit from "true"?

Comment 35

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/410f33dfbc89

Comment 36

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Patrick, given that FF44 is affected, should we consider uplifting this to Aurora?

Comment 37

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Tracked for 44.

Comment 38

[Patrick McManus [:mcmanus]]

yes - daniel should nom this for 44

Comment 39

[Daniel Stenberg [:bagder]]

Comment on attachment 8687171 [details] [diff] [review]
v2-0001-bug-1207798-add-pref-to-toggle-proxy-behavior-whe.patch

Approval Request Comment
[Feature/regressing bug #]: Bug 1121800
[User impact if declined]: Users who really do not want Firefox to bypass the given proxy might feel "betrayed" by the browser when the given proxy is down/dead. Risk for unintended privacy/information leaks.
[Describe test coverage new/current, TreeHerder]: none
[Risks and why]: Low risk, this patch basically brings back old code and a pref that makes the code alter between the old and the new behavior.
[String/UUID change made/needed]: none

Comment 40

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Daniel, I was looking at the patch. Shouldn't the pref by off by default? So "network.proxy.use_direct_on_fail" should be set to false by default to be safer. And users that want to bypass the bad proxy need to change the pref setting to true.

Comment 41

[Daniel Stenberg [:bagder]]

What is Firefox supposed to do when given a proxy that it can't use?

We don't have metrics to guide us here what people will expect or assume. I looked at some competitors and they both tried to access the network directly when the given proxy was in accessible - in an attempt to work around erroneous configurations - possibly most common when moving in and out of networks using specified proxies.

This made us (me) introduce the "try direct when proxies fail"-approach in the first place and I did discuss the default choice with :mcmanus and we both considered the current choice (the new behavior) to be the better default option.

I personally think that the amount of users who want Firefox to actually fail hard when the proxy is inaccessible is the minority of the two user groups, but I don't *know* this.

Comment 42

[mike]

(In reply to Daniel Stenberg [:bagder] from comment #41)
> What is Firefox supposed to do when given a proxy that it can't use?

The crux of the issue, from my perspective, is the failure of a proxy which has been working and spontaneously becomes unreachable. For a SOCKS proxy specifically, a user might expect to have some degree of protection in a "hostile" network. Sensitive data that the user expects to travel through the proxy is exposed without any warning if the SSH connection fails. Even if the connection is re-established, Firefox will continue to use the network without a proxy.

It's ridiculous to have a default behavior that silently undermines security. At the very least, an obvious warning that connection to the proxy failed should be presented.

Comment 43

[stephen]

> For a SOCKS proxy specifically, a user might expect to have some degree of protection in a "hostile" network.

The reason I submitted a dupe of this bug is precisely that: my primary use case of firefox is that it is a browser I can trust to not undermine my privacy and security. I was startled (to say the least) when I noticed my ssh connection was down and yet I could still surf the internet. Fortunately my life doesn't depend on this, but I know that there are others not as fortunate.

I propose that the original behavior be retained: by default protect the user.

In addition to this perhaps add a convoluted mechanism (similar to accepting an invalid cert) to disable: give them buttons in awkward places that toggles the default defensive value to be more liberal, but only after the user has demonstrated the true desire to fly in the Danger Zone.

Comment 44

[Tanvi Vyas[:tanvi]]

Is there an about:config pref to not fall back to the network when a proxy fails?  That may be sufficient for users who do not want to fallback to the network.

Comment 45

[:Gijs (out for now; he/him)]

(In reply to Tanvi Vyas [:tanvi] from comment #44)
> Is there an about:config pref to not fall back to the network when a proxy
> fails?  That may be sufficient for users who do not want to fallback to the
> network.

There is, the problem is that some people want it to default to "don't fall back" rather than the current default (which is to fall back).

Comment 46

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Daniel, Al: Would you be able to comment on whether we should be operating in "safe by default" mode or not? Please see comment 41 as it provides a lot of good data on why we are choosing to bypass proxy in case of bad URL/unreachable situation by default.

Comment 47

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

(In reply to Daniel Stenberg [:bagder] from comment #41)
> What is Firefox supposed to do when given a proxy that it can't use?
> 

We could have a check box on the "Connection Settings" dialog box where proxy settings are configured that clearly indicates "If the proxy server is unreachable, bypass the server and connect directly". And this checkbox maps to the pref which is enabled by default (your patch as is) and the UI checkbox is enabled.

I know this requires string and UI changes and would make Aurora uplift difficult. But it is a suggestion worth making.

Comment 48

[Daniel Veditz [:dveditz]]

If someone has gotten as far as opening about:preferences#advanced, clicking on the networking tab, and clicking on the "Configure how Firefox connects to the internet" button they're pretty serious. When they see a detailed screen for setting up their proxies they expect it to be detailed. There is nothing on that dialog that even hints "we will ignore these settings". I would strongly prefer that network.proxy.use_direct_on_fail default to false, but if we don't then we absolutely need a checkbox pref on that proxy setting dialog for it so the security/privacy conscious people who made it this deep have a chance of noticing that we default to betraying them.

Another option (not mutually exclusive with the above) would be to enhance the network failure page so that if a proxy is set and we can't reach the proxy at some point, AND network.proxy.use_direct_on_fail is false, we present a "Try without the proxy" button in addition to the try again button. If a user presses that button then we flip the pref to true (so the user isn't bothered in the future) and try again.

Comment 49

[Tanvi Vyas[:tanvi]]

Not all users who set a proxy are "advanced" users.  They may do so because their employer told them to do it - they followed the steps provided to them without much understanding of what they were doing.  When they take their laptop home and can't connect to the internet, they don't understand why.  Which is why the fallback to network behavior exists.

But it is a problem for the advanced users who do understand and never want to browse without the proxy.  A check box in the advanced settings is really the best option here.  It requires a little frontend work (a string and adding a checkbox).  We can get help from UX on the string and UI placement.  But I don't think we will get frontend resources to add the checkbox in the immediate future.  Can platform add the checkbox?

Dan's suggestion about a "try without proxy" option would be similar to what happens when you are in Firefox Offline Mode and try to connect to a site that isn't in your cache.  But I think this could be a v2 feature.

(In reply to Daniel Veditz [:dveditz] from comment #48)
> we present a "Try without the proxy" button in addition to the try again
> button. If a user presses that button then we flip the pref to true (so the
> user isn't bothered in the future) and try again.
If the user presses that button, we should let the user browse without the proxy this time but I'm not convinced we should flip the pref to true.  It could just be a one time thing.  We could add a "remember my decision" option.

Comment 50

[Masatoshi Kimura [:emk]]

Note that currently Aurora will fallback without proxy (that is, it is equivalent to network.proxy.use_direct_on_fail=true) and it does not even have an option to disable the fallback. So uplifting is strict improvement.
Could you approve uplift this first and then file a follow-up bug about flipping the default?

Comment 51

[Patrick McManus [:mcmanus]]

This thread is complicated, so this is my summary:

There have always been cases where a proxy was configured but not accessible and so we fell over to DIRECT. see comment 0 and comment 5. However this was inconsistent (and slow). but it has always been there. (I mention this because the discussion has shifted to backwards compatibility of the new preference)

in bug 1121800 (landed in firefox 44) :bagder made this fallback happen faster and more consistently to ease transitions between office and home.

in comment 15, tanvi suggests a checkbox "that is unchecked by default in about:Preferences->Advanced->Network->Connection Settings that says something like:
If the proxy is unavailable, do not connect to the internet"

in comment 31, :bagder landed a pref (firefox 45) that implements tanvi's suggestion at the platform (not firefox ui) level. The default is to support the failover. This has been nominated for a backport to firefox 44, but relman hasn't weighed in yet. (I support the backportin sympathy with comment 50).

comment 41 by :bagder says that this fallback by default behavior matches other browsers.

I don't like the thought of different policies implicitly applying for different methods of configuring the proxies. That's unintuitive to me, hard to enforce - but then again its pretty much the defacto (albeit I suspect unintentional) behavior of the current release. Unfortunately that is transitive to making the decision based on proxy type (i.e. SOCKS or HTTPS being special) because something like PAC can dyanmically generate anything.

nonetheless I find Mike's comment 42 compelling for users who are upgrading. Its one thing for someone that has made it to the proxy page to see the checkbox and not check it, but its different for someone on firefox 43 with SOCKS configured to update and get this behavior on firefox 44.

a suggestion in the next comment.

Comment 52

[Patrick McManus [:mcmanus]]

I think we need to bite the bullet and do a full "v2+" implementation and backout the changes we have made in 43 and 44 until that's ready.

* backout 1121800 and 1207798.. so we'll be back to the place where we've always been

* implement a front end ui for "on proxy failed" of "always fallback, always use proxy selection, ask each time". default to ask each time.

* implement the "ask each time (with remember option)" behavior and reland 1121800

I don't see any other path that will protect our socks/https upgraded folks and also allow for easy office/home transitions.

We might want to default to "always fallback" for new installs but not for updates - that can be debated.

I suspect the platform team can take a first pass at the front end bits to at least get it started.

comments are actively sought :)

Comment 53

[Daniel Stenberg [:bagder]]

(In reply to Patrick McManus [:mcmanus] from comment #52)

> comments are actively sought :)

I'm all for this. It is a bigger take on it though so it will involve more people and be larger effort but will likely end up with something that is more useful and intuitive.

Assuming the introduction of this new concept takes at least a little while to flesh out and land, a minor variation of the procedure could be:

- leave 1121800 and 1207798 - FOR NOW
- reverse the pref so that it by default works like before (== no surprises)
- work on and land the "proper" implementation of "failed proxy", as described above.
- remove the 1121800-pref again

The difference being that there would be an existing work-around for those with the knowledge until the correct fix lands. Mostly since the code is already there and it is no effort.

Comment 54

[Patrick McManus [:mcmanus]]

(In reply to Daniel Stenberg [:bagder] from comment #53)
> 
> - leave 1121800 and 1207798 - FOR NOW
> - reverse the pref so that it by default works like before (== no surprises)

reversing the pref doesn't actually make it work like before.. some pac users were getting fallback (awkwardly) before and relying on that.. so I think it should all come out.

Comment 55

[:Gijs (out for now; he/him)]

(In reply to Daniel Stenberg [:bagder] from comment #53)
> - leave 1121800 and 1207798 - FOR NOW
> - reverse the pref so that it by default works like before (== no surprises)
> - work on and land the "proper" implementation of "failed proxy", as
> described above.

Note that you generally can't uplift changes that change frontend UI and include new strings, because of l10n string freeze on aurora and beta. So if we want UI to ship with the pref, we can't do that in 44, and we'd need to be very quick and/or preland the desired strings for 45 (which branches in 1.5 week, one of which we'll spend in Orlando).

FWIW, I'm happy to help doing code reviews (and/or general guidance) for the frontend stuff. You should also get UI/UX-review from someone like :phlsa .

(In reply to Patrick McManus [:mcmanus] from comment #54)
> (In reply to Daniel Stenberg [:bagder] from comment #53)
> > 
> > - leave 1121800 and 1207798 - FOR NOW
> > - reverse the pref so that it by default works like before (== no surprises)
> 
> reversing the pref doesn't actually make it work like before.. some pac
> users were getting fallback (awkwardly) before and relying on that.. so I
> think it should all come out.

So it sounds like this should indeed all come out. comment 52 implied this landed on 43 though, which the bugs don't reflect and would be problematic because last beta is very soon now, and rc on Monday. If something needs backing out from 43 it needs to happen fast. Patrick, can you clarify?

Comment 56

[Patrick McManus [:mcmanus]]

That's my mistake in comment 52. The impacted code is on 45 and 44, not 43.

Comment 57

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Thanks guys for having this discussion, looks like the patch nominated as is should not be uplifted to 44. I will a- this patch and wait for an updated one. As Gijs pointed out, even for 45, UI changes need to come in pretty soon as next Merge day is 12-14.

Comment 58

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8687171 [details] [diff] [review]
v2-0001-bug-1207798-add-pref-to-toggle-proxy-behavior-whe.patch

Please see the discussion that ensued and mainly comment 52 and 53 on why this is A-'d. If there is an update patch that needs to be uplifted to 44, please renominate. Thanks!

Comment 59

[Daniel Stenberg [:bagder]]

(In reply to Ritu Kothari (:ritu) from comment #58)

> Please see the discussion that ensued and mainly comment 52 and 53 on why
> this is A-'d. If there is an update patch that needs to be uplifted to 44,
> please renominate. Thanks!

I'd like to progress from here with two new bugs:

1 - for reverting the changes done for bug 1121800 and bug 1207798 - this one would then need uplifting to 44 to get it back to where we were before

2 - for the discussed new "failed proxy" handling

Comment 60

[Patrick McManus [:mcmanus]]

(In reply to Daniel Stenberg [:bagder] from comment #59)

> I'd like to progress from here with two new bugs:

yes, please do that. thanks!

> 1 - for reverting the changes done for bug 1121800 and bug 1207798 - this
> one would then need uplifting to 44 to get it back to where we were before

assuming that's a clean backout so you can land that on m-c as r=backout or r=mcmanus preapproved and then a? the portion that needs to go to aurora. please also reopen the two old bugs with dependencies on the new bug you mention below.


> 
> 2 - for the discussed new "failed proxy" handling

Comment 61

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Daniel, have we reverted this changed from 45 (which is aurora now and was nightly until last week)? Also, I am planning to wontfix this bug for FF44, because I do not think the updated UI/other changes will land in time for FF44. Agreed?

Comment 62

[Daniel Stenberg [:bagder]]

The backout of this was made in Bug 1231552, but my request to get in done in aurora 44 too seems to just have stalled.

Comment 63

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

(In reply to Daniel Stenberg [:bagder] from comment #62)
> The backout of this was made in Bug 1231552, but my request to get in done
> in aurora 44 too seems to just have stalled.

I have requested Sylvestre to take a look at this. Setting this as "disabled" for FF44.