969282 - "Use proxy for all protocols" should not copy to SOCKS.

Status: RESOLVED FIXED

(Firefox :: Settings UI, defect, P3)

Description

[Manish Goregaokar [:manishearth]]

When using the setting "use this proxy for all protocols", putting in the IP/port of a SOCKS proxy doesn't work, even though the proxy details are copied to the SOCKS field.

Which is to be expected, because this pref is actually for the HTTP/HTTPS/FTP protocols. A SOCKS proxy accepts all connections, so putting it with stuff it would override doesn't make much sense. Besides, while HTTP proxies can deal with HTTPS and FTP in a fashion, I have yet to see a proxy that can accept HTTP as well as SOCKS connections.

So the copying of the HTTP proxy details into the disabled SOCKS field is a bit misleading since it isn't used. Perhaps the field should be disabled and made empty?

Comment 1

[Mathias Homann]

I'd be against "disabling and emptying". Why not simply have the "use this proxy for all protocols" leave the socks information completely alone?

Comment 2

[Mathias Homann]

And just in case you're wondering what makes this important:

Imagine a laptop where a proxy switcher addon is used to switch between several different proxy setups:

• direct
• central squid + dante on a lan
• central privoxy + tor on a lan
• privoxy + tor on localhost
• ssh dynamic forwarding using sshsocks, plus ssh tunnels to a squid proxy

...in this kind of situation which could be more common than you'd think you have to be sure that stuff gets properly changed when you switch.

Comment 3

[Nhi Nguyen (:nhi)]

Hi! Could you prioritize this bug please? We recently fixed a bug (bug 1577862) in platform that makes the problem in the UI more obvious. Please see bug 1601871 for details on how the two are related, especially comment #19, which basically suggests that the workaround is never use the "use this proxy for all protocols" checkbox. Thanks!

Comment 4

[Mike Kaply [:mkaply]]

If we fix this in UI, we should consider a migration change in browserglue that unsets the socks proxy for cases where the network.proxy.share_proxy_settings preference is set.

Comment 5

[Blake Winton (:bwinton) (:☕️)]

Sure. After talking with people, I feel the consensus is that it's around a P3, so that's what I've put. Thanks!

Comment 6

[Mike Conca [:mconca]]

I'm a little worried this issue could expand, and that P3 (if it is the typical "fix it someday" priority) is a bit low. It's a regression in 71, which came out on Dec 3, and we received two user reports about it almost immediately (in Bug 1601871, Dec 6). So people are noticing it.

December is a pretty slow time of year, especially in the enterprise world, where this issue is most likely to be seen. Just trying to anticipate a possible "bad thing" before it grows, like when everybody is back from vacation in 2020. It's not a P1 "OMG fit it now" but I'd hate to see it linger too long. Any chance of a P2 and someone getting to this in Jan/Feb?

Comment 7

[:Gijs (he/him)]

(In reply to Mike Conca [:mconca] from comment #6)

It's not a P1 "OMG fit it now" but I'd hate to see it linger too long. Any chance of a P2 and someone getting to this in Jan/Feb?

To make this not confusing (the checkbox label is "Use this proxy for all protocols" - and then not doing that would be pretty confusing) we need a string change, and that means no uplift, so to fix this in a Jan/Feb release actually does mean P1, because it would need to make it into 73.

Comment 8

[:Gijs (he/him)]

Attachment: Bug 969282 - don't copy http proxy values to socks proxy now that we use it for websocket connections, r?mixedpuppy!,mkaply!

I also took the opportunity to fix the SSL proxy label - we shouldn't label
things "SSL" anymore in 2019, unless they really are. All the comments in
bug 969282, bug 1577862 and bug 1601871 use 'HTTPS'.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/97679241a744
don't copy http proxy values to socks proxy now that we use it for websocket connections, r=mixedpuppy,mkaply,fluent-reviewers,flod

Comment 10

[Narcis Beleuzu [:NarcisB]]

Backed out for xpcshell failures on test_ext_proxy_config.js

Backout link: https://hg.mozilla.org/integration/autoland/rev/74409a2d82fcf72799767766b758e9a28b0eaa5e
Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=282999052&repo=autoland&lineNumber=2969

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/330661a663e8
don't copy http proxy values to socks proxy now that we use it for websocket connections, r=mixedpuppy,mkaply,fluent-reviewers,flod

Comment 12

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/330661a663e8

Comment 13

[Mathias Homann]

so the fix will be in FF73, is that what "milestone: firefox 73" means?

Comment 14

[:Gijs (he/him)]

(In reply to Mathias Homann from comment #13)

so the fix will be in FF73, is that what "milestone: firefox 73" means?

Yes.

Comment 15

[Michal Novotny [:michal]]

'Also use this proxy for FTP and HTTPS' still disables SOCKS host and port fields, which IMO doesn't make sense anymore.

Comment 16

[:Gijs (he/him)]

(In reply to Michal Novotny [:michal] from comment #15)

'Also use this proxy for FTP and HTTPS' still disables SOCKS host and port fields, which IMO doesn't make sense anymore.

Yeah, this was an oversight, it's tracked in bug 1610423.

Comment 17

[Outvi V]

By the way, this problem is also on Thunderbird (as of 68.4.2). Shall I create a clone of this bug on that side?

Comment 18

[:Gijs (he/him)]

(In reply to Outvi V from comment #17)

By the way, this problem is also on Thunderbird (as of 68.4.2). Shall I create a clone of this bug on that side?

Yes; we use different dialogs. You can file a corresponding bug in the Thunderbird product.

Comment 19

[Outvi V]

(In reply to :Gijs (he/him) from comment #18)

Yes; we use different dialogs. You can file a corresponding bug in the Thunderbird product.

Thanks! Bug 1613181 is now created as a clone of this at the Thunderbird product.