There is a bug somewhere that says the installer needs to be able to deal with the proxy settings necessary to complete the install. Since the installer is collecting that information, we should save it such that the browser doesn't have to ask the same question again. This will make it look like the browser and the installer were created by the same organization :-) I think all the proxy stuff is just prefs, so it should be possible to use existing prefs munging code to get the proxy information through to the browser.

As with the installer, this was a big beta1 feedback item for activation. Nominating for beta2.

[nsbeta2+] fix by 5/16, cut or apply for exception.

Where does this stand for 5/16?

We need info for how to pass on the proxy information to the profile manager. We should have a meeting to hash this out.

Gagan, can you provide the info Sean is looking for?

Well I am assuming from the discussion above that you do get to a profile from the profile manager. And on that profile all you need to set is the proxy settings specified by the following prefs- user_pref("network.proxy.ftp", "<whatever host installer provides/uses>"); user_pref("network.proxy.ftp_port", <whatever port installer provides/uses>); likewise for HTTP and SSL (if the installer is reading those, if not then probably it should be part of the profile migration)

Ungh. There's no global space at all, everything is profile local? It might help to put this info in the default prefs.js, but that'll only affect new profiles. What about dumping the info into a flat file and letting activation look for that file when it starts up? This info is almost certainly applicable to whatever profile they attempt to activate right after installation.

If it's profile local then shouldn't we ask the user for the info at profile creation/migration time? Install time is global and we appear to be imposing global info on a local instance.

The thing is, we want activation to be smooth and just work. If we force the user to enter the data again right away, we defeat both goals. If they've just given proxy info for the installer to work, it seema 99% probable the same info applies to their activation. Most users only have one profile, so in this case local and global are the same. If we need to limit this to only sucking it in if there's exactly 1 profile we could do that.

This was marked [nsbeta2+] 5/16. We didn't have a meeting to hash this out till after that date. I have the fix on hand, reviewed, and ready to be checked in. All it does is append the proxy pref settings to Netscape 6\Defaults\Pref\All.js (it creates the file if it does not exist). Renominating for nsbeta2.

Adding those proxie preferences should just be what is required here. Gagan told me that all necko needs is the presence of these preferences to aact throught proxies. So adding it in all.js should be good enough and all that is needed.

Bhuvan, are you saying you think it's the right thing to add the proxy settings to all.js where all profiles will get those proxy settings? I'm not sure about that, but if you're sure that's the right thing, I'd like to hear why.

This feature is out per yesterdays PDT mtg. Putting on [nsbeta2-] radar.

Putting the defaults in the all.js is correct because they are the defaults. For all new profils, they'll automatically work with no further annoyance to the user. Any given profile can override those defaults by using the preferences panel to put new values in the prefs.js for that profile. Everything is consistent and the user is not asked for the same information more than once.

code to update all.js with the proxy info has been checked in, but disabled for now. Leaving this bug opened.

clearing status whiteboard. setting nsbeta3 keyword. reassigning to selmer for final verdict on what to do.

nsbeta3+, P2 with michaell's agreement. Sean, assigning back to you for the final change. Thanks for getting this in there!

Please let's not modify all.js -- if we ever patch future versions this will break the patching story. Create a new .js file with the data in the same directory and it will be loaded just fine. Be very careful with the name, we want the new settings to be loaded *after* all.js because all.js sets defaults for these that would override if processed in the wrong order. For whatever reason we process in reverse alphabetical order, so "all-proxy.js" would work (hyphen is lower than dot). "allproxy.js" will *not* work. Aargh!

pdt agrees p2 (no I'm not cheating :-)

so, Dan says no. Selmer says yes. What's the final word?

Steve, what do you think of Dan's suggestion?

I think Dan's suggestion is reasonable if you can get it fixed and reviewed by tomorrow. If that's too hard or doesn't work, we should bring this before the full pdt to understand the trade offs.

Note also that if we directly modify all.js then when the user upgrades, perhaps via the SmartUpdate site, we will overwrite these modifications when we replace all.js with the new version. Therefore a separate file is definitely a good idea.

Adding tpringle - the install and activation PM. Removing myself.

in addition to the two user_pref lines to set: user_pref("network.proxy.ftp", "[proxy server]"); user_pref("network.proxy.ftp_port", [proxy port]); I had to also set the following: user_pref("network.proxy.type", 1); This last line tells mozilla to enable "Manual Proxy settings".

ignore first patch. Second patch was r=dveditz

fixed. To verify this bug do the following (which is quicker): 1) download and save N6Setup.exe and all the files in that are in the xpi directory into a local working dir. 2) delete deflenus.xpi from the local working dir that was just downloaded. 3) run N6Setup.exe that is in the local working dir. 4) You can simply use the Recommeneded setting, but any setting will do. 5) When in the Download Options dialog, click on the Proxy Settings button 6) use the following proxy info (or your favorite server/port) chainsaw.mcom.com 8288 7) Start the installation At the end of the installation, look for ...\Netscape 6\defaults\pref\all-proxy.js The file should have your settings in it. Also if you launch netscp6.exe, create a new profile, and navigate into the Preferences|Advanced|Proxies menu (I think that's where the proxy settings is at), the manual proxy settings should be enabled with the info entered in the installer. Another test is to make sure that all-proxy.js doesn't get created if no proxy info is set in the installer.

I'd like to call attention to the fact that Sean is only saving the *FTP* proxy info that we got from the install, so this fix is not likely to help the Activation problem. Is it valid to just guess that the FTP settings will work for HTTP too? This would be trivial to do. Should we add UI to the installer to ask for HTTP proxy settings in addition, even though not really needed by the installer? That would be a larger (and therefore riskier) change, and would also require a UI change.

verified with testcases noted thanks, Sean build 2000092208

Who approved this checkin? No big, just asking -- but dveditz seems to think that this bug isn't quite fixed, or maybe a new bug should be opened? I would hate to see his questions go unanswered in the bug and in other public fora. /be

The bug is fixed as the problem was described, I'm just not sure the bug described the real problem Selmer wanted fixed.

I don't think ftp settings will work for http. Gagan, will they...? Looking at the update made by gagan long ago, it looks like we may need separate entries for HTTP unless any new improvments have happened to suffice with ftp prefs. Gagan's update : " Well I am assuming from the discussion above that you do get to a profile from the profile manager. And on that profile all you need to set is the proxy settings specified by the following prefs- user_pref("network.proxy.ftp", "<whatever host installer provides/uses>"); user_pref("network.proxy.ftp_port", <whatever port installer provides/uses>); likewise for HTTP and SSL (if the installer is reading those, if not then probably it should be part of the profile migration) "

thats correct.

Hmm. I wasn't aware of this discrepancy prior to Dan's post in this bug. Was the suggestion of using the ftp values for http a valid one? If not, I think we have to punt on this for now.

Steve, this bug is already fixed. You will need to file another bug to have this bug undone.

I don't want this bug undone. If you collect valid ftp values it's worthwhile to transmit them to the browser. I was hoping someone on the CC list could answer the http equivalence question before I try to open a new bug.

Adding the installer proxy preferences to default/prefs via all-proxy.js turns out not to have been such a good idea. See: bug 72225 for details as to how this can have many bad side effects. I have several concerns about how this feature was implemented. 1- The target audience was wrong. Selmer was concerned about users who installed Netscape 6 behind a proxy-only network, went to activate, and got firewalled. This feature should target ONLY users that are creating new profiles. If a user had Communicator 4 and was surfing successfully, migration of their prefs.js would bring in any proxy settings that would work. The current implementation forces a new set of preferences, in a way that can CHANGE the actual proxy settings between the original and the migrated profile. You can read the ugly details in bug 72225. 2- The http vs. ftp concerns were valid, and should be handled by having the installer ask the user if they would like the proxy setting saved into Netscape 6. Writting the ftp proxy preferences is probably okay because you have made a network connection that emperically proves it worked. Writing the correct http proxy preference is what you NEED for activation, but you cannot blindly do just because the same proxy server handled your ftp: URLs. Using the HTTP protocol to proxy is used by both installer (for ftp URLs) and activation (http URLs). Someone said that this would be usually right, but I do not think that is a good assumption given my experience with proxy servers. This is a confusing problem because both installer and browser are using the same network protocol to proxy, but proxy administrators may choose to handle the traffice with different servers. If a user were to run this installer on such a network, they would end up with a crippled NS6 installation that would be deaf to the network. I also believe that they would be largely unable to fix this problem, because the only reason I figured this out after 2 hours was that while canceling an install, I saw all-proxy.js out of the corner of my eye. If I had not seen that, I do not know how long it would have taken to isolate the problem. 3- another solution is to use http for transport of installer files. This would remove the "install via ftp proxy server that won't proxy http for activation" problem. Sort of the opposite problem of #2, I think eventually someone will be confused that you ask for a proxy in the installer, but do not tell them it will use ftp.

I just looked at today's Windows installer, and see that we now have a selector. This is the only bug that mentioends all-proxy.js, is there more documentation on how it's going to work with the ftp/http selector?

nominating for fix because the current implementation can cause serious connectivity problems.

Ben, I'm not sure why you've reopened this bug rather than filing a new bug. I'm also not clear on what you're asking to be fixed. The installer now allows the user to choose between ftp/http, is the problem that we're not propogating the http values yet? It would help to have a clear, concise statement of what change is required.

From reading the bug, it seemed to me that there were several design aspects of this feature that were not resolved, as well as functional aspects of this feature that were not documented. It seemed like the best place to start. I've filed and nominated the other relveant bugs, I can put a digest of them here if you would like.

added to summary for searchability

SPAM: mozilla 0.9 (and M1, and 0.8.1, etc.) has left the building. please update the target milestone so we can get a good idea of what's left for 0.9.1.

After learning more about how prefs works from Sarah, I think that what should be done is to append the values you want into default/prefs/prefs.js instead. That would get around the problems with setting being unable to set proxy back to "direct" after the installer hacks the default preferences for a profile. see bug 72225

we have more pressing issues, minusing

over to Curt.

Just installed a nightly mozilla-sea-installer on windows ... after finishing the install through the proxy, it tried to reach the mozilla start page. I realised that the proxy settings in the installer were not handed over to the browser itself! So I looked around and found this bug ... hope this gets fixed real soon! Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a+) Gecko/20020622

This feature was working for a long time, so I don't know what to say...

ashant: did you have an old profile from an earlier version? If so we'd honor its prefs instead. Is an all-proxy.js file installed next to your all.js file in the defaults\pref subdirectory where mozilla was installed?

I saw this behaviour of not using installation-time proxy settings while doing a fresh install of mozilla on a Win2k machine; there were no earlier profiles present. And yes there is a file "all-proxy.js" next to "pref.js" in defaults\pref

What are the contents of your all-proxy.js file? It should contain the proxy prefs from the installer. If you create a new profile, you should see that whatever was used by the installer is taken as the default for the profile. If you have an existing profile, w/ proxy preference lines in prefs.js, this may not work (hence, my objection to the way we implemented this).

The all-proxy.js file under C:\Mozilla\defaults\pref contains only two lines pref("network.proxy.http_port", 80); pref("network.proxy.type", 1); And I tried creating a new profile - it didn't use the installer settings, but proceeded to try and connect to mozilla.org without proxy, just as I had mentioned earlier.

Ugh. yeah. That file should also contain line that has the proxy hostname. + regression. Okay, so in either profile (original, problem profile or new profile), when you open the preferences, is the "Direct" or "manual" button selected?

Well, in the profile that I use, I've manually configured it, which means "manual" is selected. For any new profile I try to create, the "direct" button is selected ...

+nsbeta again. If this was worth being plussed before, it is worth being plussed now. Additionally, I think that there is no sense plussing the other all-proxy.js bugs unless you are going to make it work. Ashant: basically the proxy setting should be set to "manual" for all new profles, if the all-proxy.js says what you said it says. The missing hostname problem is actually bug 88211 (it's been so long, I forgot I had filed these as bugs.

taking

No resources to work on this, not stop ship. minusing.

-> RESOLVED/FIXED. I should not have reopened+regression'ed this bug, it should have been put in a separate bug after comment 52. This problem is actually still open in 1.7rc1, see bug 88211.

V/fixed. I'm double-verifying, but since many people thought I never should have re-opened, it is probably okay.