User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; FDM) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; de; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729) I want to deploy Firefox 3.6 on all of our Terminal Servers (Windows Server 2003, x86, german) and lock some functions the users shouldn't change. I created a file mozilla.txt with the following lines in it: lockPref("app.update.enabled", false); lockPref("browser.search.update", false); lockPref("extensions.update.enabled", false); lockPref("browser.startup.page", 1); lockPref("browser.startup.homepage", "http://www.abc.de"); Then i converted the mozilla.txt into mozilla.cfg with the tool "ByteShifter" and copied mozilla.cfg into the folder "C:\Programme\Mozilla Firefox". I also created a file "Sperrungen.js" in "C:\Programme\Mozilla Firefox\defaults\pref" with the only line "pref("general.config.filename", "mozilla.cfg");" in it. This tells Firefox to use mozilla.cfg as info file for settings to be locked for the ordinary user. This works fine for most of the settings except the locking of these update functions and settings. Reproducible: Always Steps to Reproduce: 1. create a mozilla.cfg file with the line lockPref("app.update.enabled", false); in it 2. Copy the file to the installation folder of firefox 3. Check options/settings->Advanced->Update, check box "Firefox" It should be greyed but is isn't. Check menu "help"-> "check for updates" should be greyed but it isn't The lines lockPref("browser.search.update", false); lockPref("extensions.update.enabled", false); lockPref("browser.startup.page", 1); lockPref("browser.startup.homepage", "http://www.abc.de"); seem to work. Their settings a greyed as they are expected to. Actual Results: The update functions of FF 3.6 are fully available for the user but i don't want them check for updates or install updates autonomously. Expected Results: "check for updates" in the help menu and the check box "fiefox" in the update tab should be greyed.
I just now tested the same with FF 3.5.8 and guess what: The settings are perfectly greyed as i want them to be! Obviously something was lost with FF3.6.
Component: Preferences → Application Update
Product: Firefox → Toolkit
QA Contact: preferences → application.update
Version: unspecified → 1.9.2 Branch
10 years ago
I think I know what is going on here and should have a fix over the weekend.
Assignee: nobody → robert.bugzilla
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Spent the weekend working on bug 530872 and will get to this during the week.
Matthias, did you include // at the beginning of the file per http://ilias.ca/blog/2005/03/locking-mozilla-firefox-settings/ With the following two lines in mozilla.txt // lockPref("app.update.enabled", false); and using the online version of the byteshifter at http://www.alain.knaff.lu/howto/MozillaCustomization/cgi/byteshf.cgi I was not able to reproduce using trunk, latest 3.6, or official 3.6
You could also just create a new mozilla.cfg that doesn't have app.update.enabled as the first pref listed to see if this is the case. btw: the menuitem would have also been disabled even without the mozilla.cfg prior to 3.6 if the account you were testing with didn't have privileges. As of 3.6 which includes the fix for bug 407875 all users can check for updates unless the pref is locked.
Screenshots that explain the difference between FF 3.5.8 and FF 3.6 in handling the mozilla.cfg file.
Hello Robert, this was it. I missed "//" in the first line of the mozilla.cfg. The problem is that you really have to know that because a lot of web sites that explain how to lock settings in firefox don't mention this. I think it's because in 3.5.x it worked without slashes in the first line (see attachment). mfg M. Metzger
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
For Mozilla at least when we don't have a patch the bug can't be resolved fixed so changing to invalid. Glad this worked out for you.
You need to log in before you can comment on or make changes to this bug.