771115 - Use System Proxy Settings is not Working where as Manual Proxy Settings working.

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[Shashank Chavan]

Attachment: nightly.jpg

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/16.0 Firefox/16.0
Build ID: 20120704030538

Steps to reproduce:

I am using a proxy with my connection which was working neatly in firefox nighly build 15.


Actual results:

When I upgraded Nightly to Build 16; the "use system proxy" is not working showing 'server not found' but using the same proxy with "manual proxy configuration" its working and being able to surf.

Comment 1

[Matthias Versen [:Matti]]

What is in the system settings ?
You have a socks proxy setup in your Firefox settings and I'm pretty sure that this isn't correct. Could it be that you have added a socks proxy setting in windows ?

Comment 2

[Shashank Chavan]

Actually that proxy is only HTTP/HTTPS supported.
I checked that what you have said. But still after checking that,there is no problem in that.
I am posting system proxy setting Screen Shot and I had checked and unchecked that Automatically Detect Settings box and tried to Run Nightly 16 with Use System Settings but it is not working yet.
Everything is same as like Nightly 15 but problem is being occur only in Nightly 16.
For your confirmation may I post Screen Shot of Nightly 15 for your reference?
After checking both Nightlies in Windows XP also,now I am 100% sure that it is the bug in Nightly 16 only.!

Comment 3

[Shashank Chavan]

Attachment: System Proxy Settings.

System Proxy Settings.

Comment 4

[Matthias Versen [:Matti]]

What happens if you change the config setting in the system with the advanced button visible in your screenshot and enter a proxy in every protocol except socks ?

It would really help if you could find the 2 builds (the last working and the first broken one) where this regressed.

If you want to do this download the different nightly builds from the ftp server and test them. I would use the zip builds that can be extracted somewhere. Close any open Firefox and load the extracted Firefox.exe
ftp://ftp.mozilla.org/pub/firefox/nightly/ , use the mozilla-central builds and and example file is "firefox-16.0a1.en-US.win32.zip"

If you have found the 2 builds we need the build id from about:buildconfig
Example: Built from http://hg.mozilla.org/releases/mozilla-release/rev/f48d675ffa9f

I can't do that myself because i don't have a http proxy (only socks)

Comment 5

[Shashank Chavan]

Attachment: All Screen Shots of Nightly Builds 15 and 16.

Ok but Currently i am using Latest build of Nightly 16 but that Nightly 15 is in Aurora Channel now.!
That Advanced button is just for to use that proxy for all connections nothing else.
The build of Nightly 15 is from 
http://hg.mozilla.org/mozilla-central/rev/cfaf90b22fc3 and 
the build of Nightly 16 is from 
http://hg.mozilla.org/mozilla-central/rev/675f55c4310c .

I have posted now all 3 screen shots which are describing the BUG clearly.!

Comment 6

[Matthias Versen [:Matti]]

moving to networking
I'm unable to reproduce because i have no http proxy for testing.
The regression range from the reporter doesn't help much because the builds are several days apart with several checkins

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cfaf90b22fc3&tochange=675f55c4310c

Comment 7

[Josh Matthews [:jdm]]

Proxy/SOCKS-related checkins that stick out in that range: bug 767506, bug 763352, bug 449251, bug 767159.

Comment 8

[Masatoshi Kimura [:emk]]

(In reply to chavanshashank from comment #5)
> Ok but Currently i am using Latest build of Nightly 16 but that Nightly 15
> is in Aurora Channel now.!
"Build" doesn't mean major version number here. We want a regression range as narrowly as possible, like "between 16.0a1 (2012-07-05) and 16.0a1 (2012-07-04)".
Could you narrow down the regression range much further?

Comment 9

[Shashank Chavan]

(In reply to Josh Matthews [:jdm] from comment #7)
> Proxy/SOCKS-related checkins that stick out in that range: bug 767506, bug
> 763352, bug 449251, bug 767159.

No these bugs are not similar with that i am mentioning here.

Comment 10

[Shashank Chavan]

(In reply to Masatoshi Kimura [:emk] from comment #8)
> (In reply to chavanshashank from comment #5)
> > Ok but Currently i am using Latest build of Nightly 16 but that Nightly 15
> > is in Aurora Channel now.!
> "Build" doesn't mean major version number here. We want a regression range
> as narrowly as possible, like "between 16.0a1 (2012-07-05) and 16.0a1
> (2012-07-04)".
> Could you narrow down the regression range much further?

The regression range is also in Attachment 3 [details] [diff]. but still i am mentioning that build dates.Actually i am not getting what "regression range" is. :/

The build date of Nightly 16 is 16a1(2012-07-05).
and build date of Build 15 was 15a1 (2012-4-30).

Comment 11

[Shashank Chavan]

The attachment 3 [details] [diff] [review] All Screen Shots of Nightly Builds 15 and 16.
https://bugzilla.mozilla.org/attachment.cgi?id=639477

Comment 12

[Matthias Versen [:Matti]]

>No these bugs are not similar with that i am mentioning here. 
That doesn't matter. You have found a new bug and a new bug that didn't exists in earlier builds can only be caused by an incorrect change of the source code. Changes to the source code are only made to fix other bugs. The mentioned bug reports are in the Proxy/socks/networking area and one of this bug fixes is causing your bug. 

regression range means that a bug appeared as example in build 2012-07-06 and it worked in build 2012-07-05. With the build revision from this 2 builds we can look what have changed in the source code between those 2 builds.

A new nightly build is created every (!) night and a good regression range is therefore  a time frame of 1 day. Your dates are several days apart and instead of a small list of changes we have a very big list which is less helpful.

Comment 13

[Shashank Chavan]

ok i got lil bit  about regression range.. so the regression range is "between 15.0a2(2012-06-05)(good) and 16.0a1(2012-06-05)(broken) (when ff 16.0a is introduced) and 16.0a1(2012-07-05)(broken)(up to date at the moment)".

Comment 14

[Masatoshi Kimura [:emk]]

(In reply to chavanshashank from comment #13)
> ok i got lil bit  about regression range.. so the regression range is
> "between 15.0a2(2012-06-05)(good) and 16.0a1(2012-06-05)(broken) (when ff
> 16.0a is introduced) and 16.0a1(2012-07-05)(broken)(up to date at the
> moment)".
What's the build id from about:buildconfig?
And did you actually confirm that? I don't believe just a version bump caused the regression. The difference between 15.0a1 (2012-4-30) and 15.0a2(2012-06-05) is much larger than the difference between 15.0a2(2012-06-05) and 16.0a1(2012-06-05).
The major version number (15/16) has little meaning.

Comment 15

[Shashank Chavan]

Sorry for your inconvenience, i got the regression date range with help of of #qa member "Virgil".
so the regression date range are between 16.0a1 (2012-06-14-03-05-34)(good) changeset is here 
http://hg.mozilla.org/mozilla-central/rev/3f408698a03f
and
16.0a1 (2012-06-14-07-59-12)(bad) changeset is here
http://hg.mozilla.org/mozilla-central/rev/983b91e5aa17

Comment 16

[Josh Matthews [:jdm]]

Unfortunately that range doesn't appear to make any sense: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3f408698a03f&tochange=983b91e5aa17

I don't see anything that looks remotely connected to networking or proxies in that list.

Comment 17

[Shashank Chavan]

should i post screen shot of them?? for your reference?? i am not your developer that i will understand that completely.!

Comment 18

[Shashank Chavan]

Attachment: Left Image 16.0a1 (2012-06-14-03-05-34)(good) And Right 16.0a1 (2012-06-14-07-59-12)(broken)

see here those builds.

Comment 19

[Virgil Dicu [:virgil] [QA]]

(In reply to Josh Matthews [:jdm] from comment #16)
> Unfortunately that range doesn't appear to make any sense:
> http://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=3f408698a03f&tochange=983b91e5aa17
> 
> I don't see anything that looks remotely connected to networking or proxies
> in that list.

Not familiar with inbound, but I think he checked it on mozilla-central so woulnd't the pushlog be the following?

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3f408698a03f&tochange=983b91e5aa17

Comment 20

[Josh Matthews [:jdm]]

Yes, well spotted. Bug 563169 looks suspicious in that range. Any thoughts, Masatoshi?

Comment 21

[Masatoshi Kimura [:emk]]

Hm, it seems to fail to read the system proxy settings somehow.

Comment 22

[Masatoshi Kimura [:emk]]

Attachment: Test program to get the system proxy settings

chavanshashank, could you execute this program and paste the result?

Comment 23

[Masatoshi Kimura [:emk]]

Attachment: Source code

Comment 24

[Shashank Chavan]

The output of that program with running and without running Administrator is same that is;

FLAGS_UI: AUTO_DETECT
FLAGS: AUTO_DETECT
PROXY_SERVER: <null>
PROXY_BYPASS: <null>
AUTOCONFIG_URL: <null>

Comment 25

[Shashank Chavan]

(In reply to Masatoshi Kimura [:emk] from comment #22)
> Created attachment 639792 [details]
> Test program to get the system proxy settings
> 
> chavanshashank, could you execute this program and paste the result?

Result was 
FLAGS_UI: AUTO_DETECT
FLAGS: AUTO_DETECT
PROXY_SERVER: <null>
PROXY_BYPASS: <null>
AUTOCONFIG_URL: <null>

Comment 26

[Masatoshi Kimura [:emk]]

Hm, indeed bug 563169 was the cause.
Are you using dial-up connection, VPN, PPPoE or something to connect the Internet?

Comment 27

[Shashank Chavan]

(In reply to Masatoshi Kimura [:emk] from comment #26)
> Hm, indeed bug 563169 was the cause.
> Are you using dial-up connection, VPN, PPPoE or something to connect the
> Internet?

yup. I am using dial up connection to connect internet.

Comment 28

[Masatoshi Kimura [:emk]]

Attachment: Test program v2

Thanks. Please execute this program and paste the result.

Comment 29

[Masatoshi Kimura [:emk]]

Attachment: Source code

Comment 30

[Shashank Chavan]

(In reply to Masatoshi Kimura [:emk] from comment #28)
> Created attachment 639980 [details]
> Test program v2
> 
> Thanks. Please execute this program and paste the result.

The result of that program is -

connected: 1
connection flags: MODEM PROXY RAS_INSTALLED CONFIGURED
connection name: bsnllive
FLAGS_UI: PROXY
FLAGS: PROXY
PROXY_SERVER: 10.220.67.131:8080
PROXY_BYPASS: <null>
AUTOCONFIG_URL: <null>
RasEnumEntries failed <603>

Comment 31

[Masatoshi Kimura [:emk]]

Thank you very much for your cooperation. I'll submit a fix soon.

Comment 32

[Masatoshi Kimura [:emk]]

Attachment: Get System Proxy Settings from the active Internet connection

Comment 33

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6b0d194eabed

Comment 34

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/6b0d194eabed

Comment 35

[Jason Duell]

Comment on attachment 639995 [details] [diff] [review]
Get System Proxy Settings from the active Internet connection

Sorry this is a drive-by nomination--the patch doesn't look too big, and we're getting complaints of Yahoo Mail users getting logged out every 10 minutes when using FF 13, that might be fixed by this:
 
  http://support.mozilla.org/en-US/questions/929340#answer-350342
  https://support.mozilla.org/en-US/questions/928922?page=2#answer-344319

from a glance over the bug comments, it looks like this regressed in bug 563169--except that that bug was fixed for FF 16, so I'm not sure of the actual regression path here (or certain that this fixes the issue).  Can bug fixers/reviews comment?

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 563169
User impact if declined: 
Testing completed (on m-c, etc.): 
Risk to taking this patch (and alternatives if risky): 
String or UUID changes made by this patch:

Comment 36

[Alex Keybl [:akeybl]]

(In reply to Jason Duell (:jduell) from comment #35)
> Comment on attachment 639995 [details] [diff] [review]
> Get System Proxy Settings from the active Internet connection
> 
> Sorry this is a drive-by nomination--the patch doesn't look too big, and
> we're getting complaints of Yahoo Mail users getting logged out every 10
> minutes when using FF 13, that might be fixed by this:
>  
>   http://support.mozilla.org/en-US/questions/929340#answer-350342
>   https://support.mozilla.org/en-US/questions/928922?page=2#answer-344319
> 

This is bug 774790, for reference.

> from a glance over the bug comments, it looks like this regressed in bug
> 563169--except that that bug was fixed for FF 16, so I'm not sure of the
> actual regression path here (or certain that this fixes the issue).  Can bug
> fixers/reviews comment?

Please also comment on the risk of taking this patch. THanks!

Comment 37

[Masatoshi Kimura [:emk]]

(In reply to Jason Duell (:jduell) from comment #35)
> Sorry this is a drive-by nomination--the patch doesn't look too big, and
> we're getting complaints of Yahoo Mail users getting logged out every 10
> minutes when using FF 13, that might be fixed by this:
>  
>   http://support.mozilla.org/en-US/questions/929340#answer-350342
>   https://support.mozilla.org/en-US/questions/928922?page=2#answer-344319
> 
> from a glance over the bug comments, it looks like this regressed in bug
> 563169--except that that bug was fixed for FF 16, so I'm not sure of the
> actual regression path here (or certain that this fixes the issue).  Can bug
> fixers/reviews comment?

This bug changes the code introduced in bug 563169. I don't think it can be a cause of a regression of older branches because it is not even landed.

That said, if Yahoo! Mail users do not see the problem using latest Nightly, it would make sense to nominate BOTH bug 563169 and this bug.

Comment 38

[Jason Duell]

Comment on attachment 639995 [details] [diff] [review]
Get System Proxy Settings from the active Internet connection

It looks like the most proximate cause (like puns?) of the yahoo re-login issue is bug 767005 (aka regression caused by 235853).  Clearing nomination for this bug--if we fix 767005 and we still have issues, I agree with :emk that nomming this and bug 563169 would be worth investigating.