Closed Bug 1346711 Opened 8 years ago Closed 8 years ago

Manual proxy settings - "No Proxy for:" ignored

Categories

(Core :: Networking, defect)

54 Branch
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla55
Tracking Status
firefox-esr45 --- unaffected
firefox52 --- unaffected
firefox-esr52 --- unaffected
firefox53 --- unaffected
firefox54 + fixed
firefox55 --- verified

People

(Reporter: adrian_007, Assigned: valentin)

References

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0 Build ID: 20170312004006 Steps to reproduce: 1. Connect to VPN network that adds new network interface 2. Start local SSH tunnel that works as SOCKS5 proxy 3. Set up manual proxy settings to use SOCKS5 server and port from step 2. 4. Set up "No Proxy for:" field to domain that is accessible without proxy 5. Visit domain picked for step 4 Actual results: Unable to connect - connection was made using configured proxy Expected results: Successful connection to domain, bypassing proxy
This issues was not reproducible last Friday - last update that have been automatically installed broke it. Exact version: 54.0a2 (2017-03-12) (32-bit) Update channel: aurora
Component: Untriaged → Networking
Product: Firefox → Core
Adrian, it looks likea fresh regression in FF54/55. Could you install the tool mozregression to narrow down a regression range, please. See http://mozilla.github.io/mozregression/ for details. Run the command "mozregression --bits=32 --good=53" (or older like 52), make the test for each build downloaded by the tool and enter if the build is good or bad. After the run, copy here the final pushlog from the repository mozilla-inbound. You can use a testing profile with mozregression, with the command --profile if need be.
Flags: needinfo?(adrian_007)
I tried running this tool (Windows 10 x64, Python 2.7), but every version I've checked was good (55, 54, 53). Unfortunately I was unable to configure this tool in a way that that it would use Firefox Developers Edition (which I am running), though I guess it wouldn't make much of a difference. I also tried running my current instance in a safe mode - this didn't help proxy settings.
Flags: needinfo?(adrian_007)
Okay, so I actually did manage to reproduce it with mozregression tool: central: 9:47.90 INFO: Last good revision: ae91b2b5bb69ffd18b4679188730d0c6af3b4a95 9:47.90 INFO: First bad revision: 9e7b1041929fccc06f6fad91cf66b9edcdfc0129 9:47.90 INFO: Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ae91b2b5bb69ffd18b4679188730d0c6af3b4a95&tochange=9e7b1041929fccc06f6fad91cf66b9edcdfc0129 inbound: 14:08.36 INFO: Last good revision: 2286081f1ce3fa6d38d8d14cc2ecee918b6ab252 14:08.36 INFO: First bad revision: adc12dd054ca8c318bd2976a9015e1d43f373c30 14:08.36 INFO: Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2286081f1ce3fa6d38d8d14cc2ecee918b6ab252&tochange=adc12dd054ca8c318bd2976a9015e1d43f373c30 The problem seems to be very trivial - Firefox expects domain list of "No Proxy for:" setting to be a comma-separated list, where mine was space separated: .corporate-domain.com .testing-domain.com .vpn 10.0.0.0/24 127.0.0.0/16 localhost When I change it to comma-separated list, it works just fine.
[Tracking Requested - why for this release]: Regression Adrian, thank you for the report and finding the regression range Valentin, can you fix this regression from bug 1334443 before it moves to Beta, please?
Blocks: 1334443
Status: UNCONFIRMED → NEW
Has STR: --- → yes
Ever confirmed: true
Flags: needinfo?(valentin.gosu)
The changeset landed in bug 1334443 didn't actually fix the crashes, so I think it's safe to back it out.
Assignee: nobody → valentin.gosu
Flags: needinfo?(valentin.gosu)
> The problem seems to be very trivial - Firefox expects domain list of "No > Proxy for:" setting to be a comma-separated list, where mine was space > separated: > > .corporate-domain.com .testing-domain.com .vpn 10.0.0.0/24 127.0.0.0/16 > localhost > > When I change it to comma-separated list, it works just fine. Did the space separated list work before the update?
Flags: needinfo?(adrian_007)
Yes, had tested that with 52.0 and 53.0b1.
Flags: needinfo?(adrian_007)
proxy_GetStringPref also strips whitespace, thus it breaks parsing a space separated list MozReview-Commit-ID: F9SoMkbI28z
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Comment on attachment 8847116 [details] [diff] [review] Backout changeset 36839839cfa7 (bug 1334443) Approval Request Comment [Feature/Bug causing the regression]: bug 1334443 [User impact if declined]: "No Proxy for:" field can't parse space separated domain lists [Is this code covered by automated tests?]: no [Has the fix been verified in Nightly?]: pending [Needs manual test from QE? If yes, steps to reproduce]: yes. comment 0 [List of other uplifts needed for the feature/fix]: none [Is the change risky?]: no [Why is the change risky/not risky?]: just reverts to previous behaviour [String changes made/needed]: none
Attachment #8847116 - Flags: approval-mozilla-aurora?
Track 54+ for regression. Hi Brindusa, could you help find someone to verify if this issue was fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(brindusa.tot)
Target Milestone: --- → mozilla55
I've tried to reproduce the bug on Aurora 54.0a2 20170321084743 on Ubuntu 16.04 and on Nightly 55.0a1 20170321110237 and for both versions it worked for me, so, I'm assuming at this point that this is a bug that affects only Windows/Mac!? As I didn't have time at this point to try to reproduce it and verify it on Windows/Mac, Adrian, could you please jump in and help verify if the bug is fixed on the latest Nightly on Windows10?
Flags: needinfo?(brindusa.tot) → needinfo?(adrian_007)
54.0a2 (2017-03-21) (32-bit) - issue is no longer reproducible.
Flags: needinfo?(adrian_007)
I'm sorry - didn't check it properly. It is still reproducible when I use only spaces as separator.
(In reply to Adrian Florinescu [:AdrianSV] from comment #14) > I've tried to reproduce the bug on Aurora 54.0a2 20170321084743 on Ubuntu > 16.04 and on Nightly 55.0a1 20170321110237 and for both versions it worked > for me, so, I'm assuming at this point that this is a bug that affects only > Windows/Mac!? The issue still reproduces (as expected) with 54.0a2 20170322 at least on Windows 8.1 and Xubuntu 16.04 LTS. If you visited the requested page before, Firefox might load it from cache. Press Ctrl+Shift+R to prevent that. It's also fixed on
Adrian, this is fixed only on Nightly builds version 55.0a1. Could you please get the latest Nightly build from http://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/ and check this again? Thanks
Flags: needinfo?(adrian_007)
Tested with 55.0a1 Nightly - issue is fixed
Flags: needinfo?(adrian_007)
Comment on attachment 8847116 [details] [diff] [review] Backout changeset 36839839cfa7 (bug 1334443) backout a crashing patch. aurora54+
Attachment #8847116 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Based comment 14 and comment 19 marking verified as fixed on Nightly 55.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: