Proxy: migrated ("network.proxy.type", 3) fails to connect

RESOLVED FIXED in mozilla0.9.9

Status

()

defect
P3
normal
RESOLVED FIXED
18 years ago
18 years ago

People

(Reporter: grasso, Assigned: bbaetz)

Tracking

Trunk
mozilla0.9.9
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Reporter

Description

18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
BuildID:    2001121703

After having installed Mozilla, no HTTP connection possible (ftp works). When I 
go into options - advanced - proxies I see that no radio button is active, they 
are all blank. I can turn it on (e.g. "direct connection to the internet"), but 
if I close and reopen the options window then the setting is lost, all radio 
buttons are blank again. 

Reproducible: Always
Steps to Reproduce:
See above

Actual Results:  See above

Expected Results:  See above

See above

Comment 1

18 years ago
pulling an early morning build is always dangerous!  you might want to try a
later build to be sure that it has been tested.  that is, every weekday morning
q/a runs smoketests on the previous nights builds.  if big glarring problems are
detected then no one is allowed to make any more code changes until the problems
are resolved.  maybe you're just seeing one just problem??
Does this happen with a clean profile?
Reporter

Comment 3

18 years ago
It happens with 0.9.6 milestone, too. But I didn´t test it with a clean profile 
- I guess that´s it, some incompatible setting left from Ns4. 

I won´t be at home until new year, but I´ll have a try on my mother´s computer.
Reporter

Comment 4

18 years ago
The problem was due to these lines adopted from Ns4:

user_pref("network.hosts.socks_server", "192.168.1.3");
user_pref("network.proxy.autoconfig_url", 
"http://proxyconf.telebel.de/ns-proxyconf");
user_pref("network.proxy.ftp", "192.168.1.3");
user_pref("network.proxy.gopher", "192.168.1.3");
user_pref("network.proxy.http", "192.168.1.3");
user_pref("network.proxy.http_port", 3128);
user_pref("network.proxy.no_proxies_on", ".telebel.de");
user_pref("network.proxy.ssl", "192.168.1.3");
user_pref("network.proxy.type", 3);
user_pref("network.proxy.wais", "192.168.1.3");

I had made some experiments with a local proxy server. I hoovered that junk it 
and now Mozilla works!

Comment 5

18 years ago
sounds like you had incorrectly modified or deleted items from a preference file
so I would say this misbehavior would be expected.

marking invalid
Status: UNCONFIRMED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → INVALID
Reporter

Comment 6

18 years ago
Hey baby, why don´t you read the whole thread unless you do that? Once more:

I had configured Ns4 in some way. Not by modifiing a preference file but simply 
by filling in the form. So NS4 had written some stuff into its pref.js.  Anyway 
Ns4 doesn´t matter since I have finally overridden my special settings by 
checking "direct connection to internet".

Now, when Mozilla converted that user profile, it read pref.js and made up its 
mind how to deal with it. Obviously it did it wrong. Now, I examined the pref.js 
of that Mozilla user and found some lines which looked suspicious. I deleted 
them so Mozilla uses default settings now.    
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Isn't this a profile migration bug then?
Reporter

Comment 8

18 years ago
Not necessarily. At least two sections are involved, that is the making and the 
interpretation of prefs.js. It does not look like a HTTP networking bug, right, 
maybe "Preferences: Backend" was better. BTW, I changed the bug severity to 
"normal".
Severity: blocker → normal
Reporter

Comment 9

18 years ago
I changed the bug´s component to "preferences". Maybe I still have a chance of 
getting that bug confirmed... ;-)
Component: Networking: HTTP → Preferences
This is definitely not preferences (that component is for the UI anyway).

Over to profile migration to investigate.
Assignee: darin → racham
Status: UNCONFIRMED → NEW
Component: Preferences → Profile Migration
Ever confirmed: true
QA Contact: tever → ktrina

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2

Comment 11

18 years ago
Reassigning to Installer-ProfileMigration does not take place until after the 
Installation

Sean, does Installer read any prefs.js file (and proxy) information before doing 
the install?  I thought any prefs used in installation would be in all-proxy.js 
Assignee: racham → syd
Status: ASSIGNED → NEW
Component: Profile Migration → Installer
Please correct me if I'm wrong, but I see no mention that proxy settings were
used in the installer itself. This really does sound like a problem with the
migrated prefs. It might be profile migration, but since profile migration
really doesn't know much about converting specific prefs and network should
defend against bogus values anyway I'm bouncing back to networking.

in the nsProtocolProxyService mUseProxy is set from network.proxy.type without
checking for bogus or obsolete values, and then in 
nsProtocolProxyService::ExamineForProxy the leftover type 3 would be treated as
if it were type 1 without doing the CanUseProxy() check. Don't know if that's
the problem in this bug, but appears wrong nonetheless.
Assignee: syd → neeti
Component: Installer → Networking
QA Contact: ktrina → benc
Note that part of the problem is that Mozilla is using the same pref as
Communicator, but with different values. In Communciator type 3 was the default
and Mozilla seems to use type 0 for this.

http://developer.netscape.com/docs/manuals/communicator/preferences/newprefn.html#network_proxy_type

Comment 14

18 years ago
cc'ing bbaetz, since he loves PPS stuff ;-)
Assignee

Comment 15

18 years ago
Oh, joy. Yeah, we should accept invalid values as no-proxy.

Comment 16

18 years ago
-> bbaetz
Assignee: neeti → bbaetz
Assignee

Comment 17

18 years ago
I'll change 3 to 0, internally, I think (and default to 0)
Status: NEW → ASSIGNED
OS: Windows 98 → All
Priority: -- → P4
Hardware: PC → All
Target Milestone: mozilla1.2 → mozilla0.9.8
Assignee

Updated

18 years ago
Priority: P4 → P3
Target Milestone: mozilla0.9.8 → mozilla0.9.9

Comment 18

18 years ago
So, I gueess this means we will use "4" for the next proxy mode we add? :)
Summary: No HTTP connection - "options - advanced - proxies" misbehavior → Proxy: ("network.proxy.type", 3)
The changed summary didn't mean much to me, hope you don't mind the update.
Summary: Proxy: ("network.proxy.type", 3) → Proxy: migrated ("network.proxy.type", 3) fails to connect

Comment 20

18 years ago
much better. no point in having be something that only makes sense to me...
Assignee

Comment 21

18 years ago
Posted patch patchSplinter Review
OK, here we go. I tested it, and it appears to work. I have to use a proxy from
my university, but I verified that I got the expected "you have to use a proxy"
timeout, and that the pref was correctly updated.
Comment on attachment 66864 [details] [diff] [review]
patch

sr=dveditz assuming you get darin to r= (otherwise I'll want to dig deeper)
Attachment #66864 - Flags: superreview+

Comment 23

18 years ago
Comment on attachment 66864 [details] [diff] [review]
patch

>Index: netwerk/base/src/nsProtocolProxyService.cpp

>+                if (!pref) {
>+                    mPrefs->SetIntPref("network.proxy.type", 0);
>+                }

nit: eliminate unnecessary braces to be consistent with existing coding style
in nsProtocolProxyService.cpp

r=darin
Attachment #66864 - Flags: review+
Assignee

Comment 24

18 years ago
Checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
*** Bug 124098 has been marked as a duplicate of this bug. ***
*** Bug 117460 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.