Toolbar button preferences don't get locked down on the toolbar if lockPref function is used and the value is set to false (or in one case true). Chip found that when you lockdown a certain toolbar pref in either the all-ns.js file or a hashed CFG such as... i.e. lockPref("browser.toolbars.showbutton.mynetscape", false); ...the preference does get locked in the General Preferences Window, but doesn't get reflected on the toolbar. For the example case specified, the mynetscape button still exists on the browser even though the value is set to false. All toolbar preferences EXCEPT... lockPref("browser.toolbars.showbutton.bookmarks", false); lockPref("browser.toolbars.showbutton.home", false); exihibit this behavior. Steps to Reproduce: 1. Delete existing prefs.js file located in your User Profile directory 2. Start the latest trunk build (2001061508 was the build I used) and verify that in the General Preferences Window, Category: Navigator, that in the "Select the buttons you want to see in the toolbars" area that all boxes are checked except for Go. 3. Quit the trunk build and edit your all-ns.js located in Path_to_install dir/defaults/pref/ directory 4. Add the following lines to the all-ns.js file to lock down the toolbar prefs: lockPref("browser.toolbars.showbutton.go", true); /* Setting this pref to true, because by default it is false. Since it is set to true, it should appear on browser window....so we thought */ lockPref("browser.toolbars.showbutton.mynetscape", false); lockPref("browser.toolbars.showbutton.net2phone", false); lockPref("browser.toolbars.showbutton.netscapeshop", false); lockPref("browser.toolbars.showbutton.print", false); lockPref("browser.toolbars.showbutton.search", false); lockPref("browser.toolbars.showbutton.netscapesearch", false); 5. Save file and start trunk build. 6. Verify that the mynetscape, net2Phone (if using windows), netscape shop, toolbar search (next to URL bar), search (on toolbar), Print, button still exist even though we specified to not show them on the toolbar. 7. Also verify that the GO button that should be located to the right of URL bar doesn't exist (we set this value to true to and locked it down so we should be able to see it on the browser window). 8. Open general prefence window and verify that the 7 of the buttons are greyed out and locked, with no check boxes marked except for the Go button, bookmarks and Home. Eddyk's comments: " Methinks this is an issue with the toolbar code and the backend. The backend should be returning the false value, but either it's not, or the toolbar is using something else to find the values. Maybe the pref observers aren't being fired off correctly when the state changes based on a locked pref?" I'm going to assign this one to brian per eddyk's comments.

still trying to learn how to attach files to bugs...but when you download the attachment, save it to your directory that has the netscp6.exe binary...save it as netscape.cfg and not showattachment.cgi.

adding nsenterprise keyword

This is a result of these preferences NOT being stored in the hashtable .... but rather being stored in the "localstore.rdf" file. There is no check for lock or not lock for these prefs when reading them, nor is their state stored in the prefs.js file. Searching for what can be done to remedy this... ie, provide check in the hashtable even though the state is stored in rdf. NOTE: locking these preferences in the cfg file does not lock them setting these preference via the Edit|Preferences menu does not write to the prefs.js file (but rather to the localstore.rdf file)

Basically what we have now is 2 methods for storing user preference data. The old prefs.js and friends, and now localstore.rdf. Localstore.rdf seems to contain a lot of previously prefs.js stuff such as: - Toolbar prefs - Sidebar prefs - Window layout prefs - Themes(?) And, I'm sure, many more that I haven't noticed. Given that many of these are items that corporate IS departments habitually lock down, we will have to come up with a way to deal with this issue. One way, I suppose, would be to apply a layer of "locking" preferences on top of the rdf preferences. This seems sub-optimal in my opinion however. cc'ing waterson for input as he seems to be the rdf guy...

There ought to be a way to point items to either the local RDF file or to a file in chrome:// But adding this functionality, we could then "lock" all the RDF values by pointing the value to the chrome:// and as a result locking it. Thinking ahead... if we need the ability to adjust the "chrome://" setting (or corporate use) we might include the ability to point to some remote RDF file located on the web.

Cleaning up keywords, cc list, etc. Sending over to RDF as these preferences are not stored using the preferences service but rather through RDF.

Bug 166455 may depends on this bug ? (or even be qualified as Dupe ??) Also, you may want to make this bug block bug 123929 ?

waterson left the building

The fix for bug bug 230219 should have fixed this.