Closed Bug 427927 Opened 17 years ago Closed 17 years ago

AutoConfig doesn't work with Trunk / Firefox 3

Categories

(Firefox :: Settings UI, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 3

People

(Reporter: kohei, Assigned: mkaply)

References

Details

(Keywords: regression)

Attachments

(1 file)

I have noticed that AutoConfig capability didn't work with Firefox 3 Alpha/Beta and Trunk. Tested on Windows and Mac. The following set of files works with Firefox 2. [Local] firefox-admin.cfg: (blank) [Local] pref/firefox-admin.js: pref("autoadmin.global_config_url", "http://admin.mozilla.local/autoconfig/firefox-admin.jsc"); pref("general.config.filename", "firefox-admin.cfg"); pref("general.config.vendor", "firefox-admin"); [Remote] .htaccess: AddType application/x-javascript-config jsc [Remote] firefox-admin.jsc: // Do not edit this section: lockPref("autoadmin.global_config_url", "http://admin.mozilla.jp/autoconfig/firefox-admin.jsc"); lockPref("general.config.filename", "firefox-admin.cfg"); lockPref("general.config.vendor", "firefox-admin"); // Client preferences: lockPref("xpinstall.enabled", false);
(minor typo: admin.mozilla.jp -> admin.mozilla.local) For testing, added pref("general.config.obscure_value", 0); to pref/firefox-admin.js, then added displayError("foo", "bar"); lockPref("xpinstall.enabled", false); to firefox-admin.cfg but nothing happened.
Summary: AutoConfig doesn't work with Trunk → AutoConfig doesn't work with Trunk / Firefox 3
Confirmed for Linux as well.
Flags: blocking-firefox3?
Keywords: regression
Need a regression range on this.
Keywords: qawanted
Where do I put firefox-admin.cfg? What directory?
I haven't tested with firefox 3 yet ... neither with svn thunderbird (where autoconfig is really relevant to my opinion for autoconfiguring mailbox reading !) anyway, I maintain a doc on autoconfig here for 2.X http://developer.mozilla.org/en/docs/MCD,_Mission_Control_Desktop_AKA_AutoConfig your question might be answered here: http://developer.mozilla.org/en/docs/MCD,_Mission_Control_Desktop_AKA_AutoConfig#firefox.cfg if it helps . I will soon test autoconfig with recent firefox/thunderbird as our university needs it for next school year starting in september 2009 .
Assignee: nobody → mozilla
Flags: blocking-firefox3? → blocking-firefox3+
Attached patch FixSplinter Review
bug 340795 broke this. autoconfig was lumped in with GTK2 system prefs. Moving back to a standalone module.
Attachment #316056 - Flags: review?
Attachment #316056 - Flags: review? → review?(benjamin)
Keywords: qawanted
Whiteboard: [has patch][needs review bsmedberg]
Attachment #316056 - Flags: review?(benjamin) → review+
Comment on attachment 316056 [details] [diff] [review] Fix Want autoconfig for FF 3.
Attachment #316056 - Flags: approval1.9?
Comment on attachment 316056 [details] [diff] [review] Fix a1.9+=damons
Attachment #316056 - Flags: approval1.9? → approval1.9+
Fix checked in.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Whiteboard: [has patch][needs review bsmedberg]
Target Milestone: --- → Firefox 3
Now it works again. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9pre) Gecko/2008042204 Minefield/3.0pre
Status: RESOLVED → VERIFIED
I'm still seeing the same issue with Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b5) Gecko/2008042314 Red Hat/3.0b5-0.beta5.3.el5 Firefox/3.0b5 but I expect it's because 3.0 beta 5 doesn't have the fix attached here... What version is that fix checked into? Or, how do I apply it?
There will be a release candidate for FF3 released very soon. you'll be able to test it there. or you can download the latest nightly: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
Awesome, thanks!
....aaaand nope, doesn't work for me in the release version on Linux, sorry. Did it get regressed again? Here's my version info and contents of the config files: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9) Gecko/2008061517 Red Hat/3.0-2.el5 Firefox/3.0 /usr/lib/firefox-3.0/dw-config.cfg: //point to the autoconfig directory on the web server lockPref("autoadmin.global_config_url", "http://proxyconfig/autoconfig/"); /usr/lib/firefox-3.0/defaults/preferences/vendor.js: pref("general.config.obscure_value", 0); pref("general.config.filename", "dw-config.cfg"); I've tried bypassing dw-config.cfg in the same manner Kohei Yoshino did. This eliminates the pop-up error 'Failed to read the configuration file", instead it fails silently.
(In reply to comment #14) WFM... Could you try again like this? /usr/lib/firefox-3.0/dw-config.cfg: // This file is empty /usr/lib/firefox-3.0/defaults/preferences/vendor.jsa: // point to the autoconfig *file* (not directory) on the web server pref("autoadmin.global_config_url", "http://proxyconfig/autoconfig/dw-config.jsc"); // this *vendor name* should be the same as the filename below pref("general.config.vendor", "dw-config"); pref("general.config.filename", "dw-config.cfg");
(In reply to comment #15) > /usr/lib/firefox-3.0/defaults/preferences/vendor.jsa: vendor.jsa -> vendor.js
Thanks, Kohei, that's what I meant when I said I tried bypassing dw-config.cfg in the same manner as you. I tried it again, following your suggestions exactly: epic fail. Same issue, although this time I got the pop-up error "failed to read configuration file". However, I think that may be a different thing. Firefox is trying to read dw-config.cfg as the config file, which is blank. I set: setenv NSPR_LOG_MODULES MCD:5 setenv NSPR_LOG_FILE ~/mozilla.log setenv AUTOCONFIG_DEBUG 1 to enable logging in the MCD module. This will cause Firefox to note when it reads the autoadmin.js file, and where it reads it from, and it reports: -134400304[805e790]: general.config.filename = dw-config.cfg not real helpful, eh? So I tried something else, something much simpler. It's not really necessary to redirect Firefox to a URL to get the config file; that's just for convenience. Firefox will read settings directly from the cfg file, so I put one setting in there: /usr/lib/firefox-3.0/defaults/preferences/vendor.js: pref("general.config.obscure_value", 0); pref("general.config.filename", "dw-config.cfg"); /usr/lib/firefox-3.0/dw-config.cfg: pref("general.config.vendor", "dw-config"); Still won't read that file - same error. At the suggestion of Red Hat engineering, I also tried using the /usr/lib/xulrunner directories instead of /usr/lib/firefox: this also didn't work. So is this just me, or is it failing for others too?
I figured it out. Well, Red Hat did. Firefox 3 in Linux requires a link in /usr/lib/firefox-3.0/defaults/ that points to /usr/lib/xulrunner-1.9/defaults/autoconfig. Once that link is there, the autoconfig works properly. Not sure if that link should be part of the base Firefox package, or packaged up by Red Hat engineers. I suspect the latter. Anyway, my contributions to this thread are, I believe, finished. Thanks for the help!
Anthony, I'am glad it finally worked for you, so I try myself to run it. I use fedora9 in 64 bit , so the lib64 directory in path below ! First I wonder where did your set the "pref("general.config.filename", "dw-config.cfg");" in: /usr/lib64/firefox-3.0/defaults/preferences/all-redhat.js or in /usr/lib64/xulrunner-1.9/greprefs/all.js next about the link RedHat suggested, I did as you recommended that [root@localhost /usr/lib64/firefox-3.0/defaults] $ ln -s /usr/lib64/xulrunner-1.9/defaults/autoconfig/ ./autoconfig and indeed the .cfg file got finally readed, thanks for the advice :-) could you give us an example of your dw-config.cfg, because mine generate error now :-( . Thanks
Yeah, I'll be happy to show my configuration again. Jehan, instead of using all-redhat.js I created a new file (Firefox is smart enough to read every js file in /usr/lib<64>/firefox-3.0/defaults/preferences/) called vendor.js. /usr/lib/firefox-3.0/defaults/preferences/vendor.js: pref("general.config.obscure_value", 0); pref("general.config.filename", "dw-config.cfg"); /usr/lib/firefox-3.0/dw-config.cfg: //point to the autoconfig directory on the web server lockPref("autoadmin.global_config_url", "http://proxyconfig/autoconfig/"); and finally, the link you described above: /usr/lib64/firefox-3.0/defaults/autoconfig --> /usr/lib64/xulrunner-1.9/defaults/autoconfig I found that if the 'lockPref("autoadmin.global_config_url","<your_url>")' line is the first line in the dw-config.cfg file, it gave me errors. That comment line eliminated the error. (?) dw-config-cfg points to a general directory, rather than a specific file, because I use the same two files for Mozilla, Thunderbird and Firefox: that directory contains an index.cgi that determines the software being used with $ENV{'HTTP_USER_AGENT'} and then points to the appropriate autoconfig file. Hope that helps.
Ok then your dw-config.cfg uses a redirection to a "global_config_url": lockPref("autoadmin.global_config_url", "http://proxyconfig/autoconfig/"); Mine doesn't redirect to a URL but sets (lock !) preferences in itself , sample few first line on mine dw-config.cfg (mine is called firefox.cfg ): //put everything in a try/catch try { //Privacy & Security defaultPref("signon.rememberSignons", false); lockPref("browser.startup.homepage", "http://www.it-sudparis.eu/"); etc ... I did that once as the "global_config_url" was broken some times ago ,and then I stick with a local to each station configuration file instead of a centralize conf file on a web server as you do, we propagate that file with cfengine on linux and powershell on windows stations (about 300 stations) . Eventually, I did that, because I though that it adds a degree of independance on the web server availability . About a comment line at the begining of the file, I also had to do it , but can't explain why, probably that the parser needs that !? However, I'am interested in the way you use a unique file for Mozilla, thunderbird and firefox based on an index.cgi and $ENV{'HTTP_USER_AGENT'}, can you give us a copy of you index.cgi and the common configuration file for the 3 applications ? Thanks.
I may have been unclear: I use the same vendor.js and dw-config.cfg file for all three packages (Firefox, T-bird, and Mozilla). Each of those has their own config file, called firefox.js, etc. The index file and its module are written in perl. Here they are: http://proxyconfig/autoconfig/index.cgi: #!/usr/bin/perl -w use strict; use configFilename; #Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 #Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 my $config_path = 'resources/js'; my $default_config = 'common-config.js'; my $config_file; $config_file = $config_path . '/' . get_config_filename(); if( ! -e $config_file ) { $config_file = $config_path . '/' . $default_config; } print ("Content-type: application/x-javascript-config\n\n"); open(TMPFILE, $config_file); while(<TMPFILE>) { print; } close(TMPFILE); and http://proxyconfig/autoconfig/configFilename.pm: #!/usr/bin/perl -w sub get_config_filename { my $browser = 'mozilla'; my $user_agent = $ENV{'HTTP_USER_AGENT'}; my $version; $browser = ($user_agent =~ /Firefox/) ? 'firefox' : ($user_agent =~ /Thunderbird/) ? 'thunderbird' : ($user_agent =~ /Seamonkey/) ? 'mozilla' : 'mozilla'; #default return $browser . '-config' . '.js'; }
This still doesn't seem to work on Windows XP Adding pref("general.config.filename", "mozilla.cfg"); to the end of all.js causes FF not to start with Failed to read the configuration file. Please contact your system administrator. This is on XP SP3 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9) Gecko/2008052906 Firefox/3.0
Indeed, on windows autoconfig for firefox-3 doesn't work for me neither :-( . I am on vista , calling autoconfig with all.js doesn't seem to do anything. I don't have errors, but nothing is "locked" and none of the displayError message I call with the setting of mine MOZILLA_DEBUG environement viriable works . HEre's what I did; 1) ask all.js to call firefox.cfg E:\Program Files\Mozilla Firefox-3\greprefs\all.js ends with //Jehan autoconfig; http://developer.mozilla.org/en/docs/MCD,_Mission_Control_Desktop_AKA_AutoConfig pref('general.config.obscure_value', 0); pref('general.config.filename', 'firefox.cfg'); 2) once irefox.cfg is called (which doesn't seem to occure :-( ) lock a default homepage: E:\Program Files\Mozilla Firefox-3\firefox.cfg //put everything in a try/catch try { // 1) env variables if(getenv("USER") != "") { // *NIX settings var env_user = getenv("USER"); var env_home = getenv("HOME");} else { // Windows settings var env_user = getenv("USERNAME"); var env_home = getenv("HOMEPATH");} var env_mozdebug= getenv("MOZILLA_DEBUG"); if (env_mozdebug) {displayError("NO ERROR , just a test, user =" + env_user); } lockPref("browser.startup.homepage", "http://www.it-sudparis.eu/" ); // Close the try, and call the catch() } catch(e) {displayError("lockedPref", e);} 3) test it E:\Program Files\Mozilla Firefox-3>set MOZILLA_DEBUG=1 E:\Program Files\Mozilla Firefox-3>set NSPR_LOG_MODULES=MCD:5 E:\Program Files\Mozilla Firefox-3>set NSPR_LOG_FILE=e:\tmp\ff3-log.txt E:\Program Files\Mozilla Firefox-3>firefox firefox shows up, but the default page is not set, nor the popup (which do work with thunderbird 2.0.0.14) of the displayError message doesn't shows up :-( . Is there a kind of links to be done as it was mentionned on linux with autoconfig -> xulrunner ? /usr/lib64/firefox-3.0/defaults/autoconfig --> /usr/lib64/xulrunner-1.9/defaults/autoconfig I don't see any xulrunner on windows firefox3 installation !? any help, greatly appreciated . Thanks .
It works, ;-) it was a stupidity of mine, I had saved a copy of greprefs/all.js as filename all-copie.js and has it kept the .js extension is was read and probably overloaded the all.js calls . now I have rename it to .old and these calls are well executed pref('general.config.obscure_value', 0); pref('general.config.filename', 'firefox.cfg'); So my lockPref("browser.startup.homepage", URL ); now works fine . However I still cannot do ldap calls :-( , but that last since early realeses of firefox, cf https://bugzilla.mozilla.org/show_bug.cgi?id=295329
Did exactly the same thing on a Vista box and it worked so I copied the all.js and mozilla.cfg back to the XP box and that now works - As far as I can see there was no difference , but there must have been something. Creating mozilla.cfg from scratch and using an old all.js and the problem is back .. copy the vista ones and it goes away so I guess it's not a bug ( just brain failure somewhere )... whatever !
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: