use Proxy Auto Config URL ------------------------- Changing pref("network.proxy.type", 2) indicate that entry in pref("network.proxy.autoconfig_url, "http://proxy/proxy.pac) is selected but it does not work even after manual reload or manual change to direct connection and back again to auto again. However, if we start and pref("network.proxy.type", 0) is used then selecting Auto Config after installation with preset autoconfig_url entry in pref("network.proxy.autoconfig_url, "http://proxy/proxy.pac"); it works. Can this be fixed so that it will use the preset autoconfig_url immediately after installation.

This is reported by harsonow@aiaa.com.au

See this on linux; OS -> All. Taking this bug.

I can reproduce this by creating a two-line prefs.js in a new profile that contains: ---- user_pref("network.proxy.type", 2); user_pref("network.proxy.autoconfig_url", "file:///scratch/pac"); -- This fails for a reason that has nothing to do with networking code -- the prefs parser is skipping the first line of the file for reasons I don't understand. PREF_EvaluateConfigScript offers this explanation: "In order to protect the privacy of the JavaScript preferences file from loading by the browser, we make the first line unparseable by JavaScript." see http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/prefapi.c#477 I'm a little confused as to what privacy this is, as the line that is being skipped usually reads "# Mozilla User Preferences". -> Preferences backend, who hopefully can shed some light on this. In the meantime, I was able to work around this problem by inserting an empty line at the top of the prefs.js file.

This is correct. Internally prefs.js is opened with the flag to skip the first line set to true. This is working as it should. When prefs.js file is written out, it is always prefixed with the header: #define PREFS_HEADER_LINE_1 "# Mozilla User Preferences" #define PREFS_HEADER_LINE_2 "// This is a generated file!" The "privacy" mentioned is to keep the browser from opening the file in a new window and either executing JS code or displaying all of the items in the prefs.js file. As the reported bug seems to imply a failure to adhere to the preference rather than a failure to read it, I am hesitant to invalidate it. Back to networking and tingly for further triage and/or invalidation.

cc'ing the original reporter in hopes of getting some extra info. tao@netscape.com, does my attempt to reproduce the problem sound like the report you received? The reporter doesn't seem to have a bugzilla account, so I'll forward a link to this bug to try to get some extra info. bnesse, I'm still a bit confused by the behavior -- if I want to insert to some default prefs into a newly created profile (e.g., I'm doing this via a script to install on many machines), I have to know to leave the first line blank, make it a comment, etc. Is this at least relnoted somewhere? Am I the only one who thinks this is strange?

prefs.js has always worked this way. This functionality comes from the 4.x codebase. If you had a script that worked for 4.x, it should work for mozilla. Like the header says, prefs.js is a generated file. It even doesn't exist until the browser has been launched once. And, honestly, there are no guarantees as to its format or contents. If the underlying functionality in prefs changed (which has been discussed) the contents of this file might change radically. Having said that... There are options. - If you are adding to an existing prefs.js file, append to the end... problem solved. - If you are in a situation where you don't have a prefs.js (I'm not entirely sure how you can have a profile without a prefs.js file)... start with a template file. - Put your defaults into "user.js" instead. - Create your own "vendor" file aka "defaults/prefs/<mystuff>.js" - Use the enterprise features (Config/AutoConfig)... yes this is somewhat more radical.

Ok, I'm satisfied. Thanks for the explanation, bnesse. Using user.js or padding out prefs.js both work for me -- mozilla starts up configured for PAC and with the correct URL, which it loads. The reporter is apparently using CCK, so I'm not entirely sure where this is going wrong.

CCK does not currently support changing the proxy settings, so I assume the user was editing the prefs manually.

so this is not a PAC bug but a js/pref bug/feature is this invalid?

I'm confused by this bug report. Ignoring all the comments about the format of the prefs.js file, I believe that this bug is saying that if you have the following lines in the file, the pac will not be used: pref("network.proxy.type", 2) pref("network.proxy.autoconfig_url, "http://proxy/proxy.pac) and furthermore the bug report is implying that this has to be hand-edited into the prefs.js because the ui does not support it. However, with a current build I am indeed able to set these prefs using the UI in the pref panel. And having done so, the specified pac file is indeed being used. So I'm closing this out as wfm. If I'm totally off base, then please reopen the bug and clearly describe what the problem is.

Stephen, why haven't you actually done what you stated in comment #10? Have you just missed the radio button or are you waiting for a comment about the bug?

I guess I forgot to click on the radio button as you said. Really closing out this time.

VERIFIED. bnesse: thanks for the additional info about prefs.js. I will update my prefs docs in that other bug soon, I've been very busy.