It might be that intl.css is overriding the userChrome.css but I suspect this is not the case. Have you used Firebug or DOM inspector in order to debug it? Are you sure you doesn't have any addons installed?

Shalom Tomer,

Thanks for your response.

I'm not familiar with intl.css, and a quick Google search didn't really tell me anything about it.

I did quickly try DOM Inspector, but I am not a web programmer and I couldn't figure out how to see the name for the Tools menu. If you know of a site with a simple explanation on using DOM Inspector to see parts of the Firefox interface (as opposed to the parts of the web page, which is what most sites about DOM Inspector write about), kindly post it here.

As far as addons, without double-checking I can say that the only addons are probably Flash and Sun Java.

-Michael

Although I think it is very stupid to hide certain UI items from users, as they can easily bypass your "protection" (Well, it has nothing to do with protecting users or the network infrastructure, but to make their life more difficult, you should apply that rule to #tools-menu instead of looking for its label.

@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");
#tools-menu { display: none !important }

p.s., you can do further hacking by pointing your web browser to chrome://browser/content/browser.xul and running an inspector on its DOM elements or just view the source of that file.

It would be better to lock the related prefs if you want to prevent user s from making changes to settings.

Use a mozilla.cfg file in the Firefox program folder to lock prefs or specify default values.
Place a file local-settings.js in the defaults\pref folder where you also find the file channel-prefs.js to specify using mozilla.cfg.

pref("general.config.filename", "mozilla.cfg");
pref("general.config.obscure_value", 0); // use this to disable the byte-shift

See:

• http://kb.mozillazine.org/Locking_preferences

You can use these functions in mozilla.cfg:

defaultPref();  // set new default value
pref();         // set pref, but allow changes in current session
lockPref();     // lock pref, disallow changes

Thanks to Tomer and Cor-el for your replies. In the end I decided to implement the solution that Tomer suggested, even though in principle I would have preferred Cor-el's method, and I'll explain why.

The difference between the 2 approaches is that Tomer's solution removed the Tools menu totally – which is what I asked about. Cor-el's solution leaves the Tools menu, but locks the proxy settings so that the user cannot change it.

My situation is that I am the systems administrator of a small college in Israel, and usually we allow the students to surf the internet when they have a class in a computer lab. However, there are certain days and hours when internet access must be blocked for various reasons. I won't go into details on how I block the internet, but one of the components of my blocking method includes setting the proxy to 0.0.0.0. The setting changes required are sent from the domain server to the workstation on the appropriate days and times.

I have both Internet Explorer and Firefox installed on my various computer- labs computers. For Internet Explorer, making the change on the workstation is fairly easy – the server sends registry changes to the workstation to set the proxy to 0.0.0.0 (as well as a homepage change that announces that internet access is currently blocked), and the students are unable to change the proxy setting since it is locked by Group Policy.

For Firefox, the process of disabling internet access by setting a proxy is a little more complicated. First the server places on the workstation a new prefs.js which defines the proxy (and a new homepage), and then it copies userchrome.css to remove the Tools menu so that the students cannot change the proxy setting back. All this worked fine until I installed 2 labs with the Hebrew version of Firefox, instead of the English version as I always have. I saw that in the Hebrew version, the Tools menu was not being removed by userchrome.css, and therefore I posted my question. Now, by using the userchome.css syntax that Tomer wrote, the Tools menu is indeed removed by Hebrew Firefox.

(So as a response to Tomer's comment that it's "stupid" to hide UI items, let me just emphasize that I do this only when the students should not be using Firefox anyway since access to the internet needs to be closed at that time.)

I would have preferred Cor-el's method of blocking the ability to change the proxy settings (which is essentially what I do with Internet Explorer), without removing the Tools menu entirely. However, a big difference between Cor-el's method and Tomer's is that Cor-el's method requires placing files in Firefox's program directory, while Tomer's method involves placing files in the user's profile directory. From a system administrator's point of view, this is a major difference.

Placing files in Firefox's program directory, would require me to later remove those files when I want to allow Firefox surfing. That means that I have to schedule the 3rd-party program on the server to do both actions (place files and remove files) at the appropriate dates and times, and that allows more opportunities for failure (ie. computer isn't turned on in order to have those files removed). In addition, I always prefer to make a change to a user profile than to a program directory.

In contrast, Tomer's method changes the user profile settings which affect Firefox, meaning that I only have to program the 3rd-party program on the server to do that one action at the appropriate times. Since all my lab computers get a mandatory user profile from the server, those settings are automatically erased when the computer is rebooted. I don't have to worry that a computer won't get reset back to the normal situation where surfing is allowed.

So I would have preferred the outcome of Cor-el's method (Tools menu still available but proxy settings locked), but not at the expense of messing with the program directory as opposed to the user profile. I am well aware that with Tomer's method the students can change the proxy settings back using about:config, but I hope that most of them aren't aware of this option.

So once again, thanks again to both of you for your assistance.

-Michael

Cor-el's suggestion is better, as it actually do something. You could set Firefox to use "system" proxy setting and lock it. Firefox will use IE setting and you won't have to bother updating its settings but IE settings.

Please keep in mind that it is very easy to bypass such protections, even if you'll use both suggestions.

Tomer.

You can of course use both versions and hide the Tools menu if you really want to prevent access to all items in that list and also lock any prefs that you do not want them to change. Locking prefs via mozilla.cfg is always in effect and can only be bypassed by removing that file and to do that you need write access to the Firefox program folder.

Be aware that the Firefox button that appears when the menu bar is hidden also has an Options entry that would need other code to hide.