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

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?

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.

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!

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

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.

Isn't this a profile migration bug then?

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

I changed the bug´s component to "preferences". Maybe I still have a chance of getting that bug confirmed... ;-)

This is definitely not preferences (that component is for the UI anyway). Over to profile migration to investigate.

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

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.

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

cc'ing bbaetz, since he loves PPS stuff ;-)

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

-> bbaetz

I'll change 3 to 0, internally, I think (and default to 0)

So, I gueess this means we will use "4" for the next proxy mode we add? :)

The changed summary didn't mean much to me, hope you don't mind the update.

much better. no point in having be something that only makes sense to me...

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)

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

Checked in

*** Bug 124098 has been marked as a duplicate of this bug. ***

*** Bug 117460 has been marked as a duplicate of this bug. ***