Closed Bug 969282 Opened 8 years ago Closed 2 years ago

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

Categories

(Firefox :: Preferences, defect, P3)

x86_64
All
defect

Tracking

()

RESOLVED FIXED
Firefox 73
Tracking Status
firefox73 --- fixed

People

(Reporter: manishearth, Assigned: Gijs)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

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?
Blocks: 1601871

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

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.

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!

Flags: needinfo?(bwinton)

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.

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

Flags: needinfo?(bwinton)
Priority: -- → P3
Flags: needinfo?(mconca)
Flags: needinfo?(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?

Flags: needinfo?(mconley)
Flags: needinfo?(gijskruitbosch+bugs)

(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.

Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Flags: needinfo?(mconley)
Flags: needinfo?(gijskruitbosch+bugs)

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'.

Pushed by gijskruitbosch@gmail.com:
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
Flags: needinfo?(gijskruitbosch+bugs)
Pushed by gijskruitbosch@gmail.com:
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
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 73

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

(In reply to Mathias Homann from comment #13)

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

Yes.

Blocks: 1610423

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

(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.

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?

(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.

(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.

Regressions: 1625773
You need to log in before you can comment on or make changes to this bug.