One of the complaints that seems to come up a lot with regards to Firefox in the enterprise is the lack of support for management via Active Directory (using Group Policies). There have actually been a couple attempts to solve this including FirefoxADM and WetDog. There is even a company, FrontMotion, that makes custom Firefox MSIs that can be managed via Active Directory.
I decided I don’t know enough about this area, so I’ve spent the past couple weeks investigating what Microsoft provides and the results actually surprised me: IE configuration via Group Policies seems to focus much more on customizing the browser(*) than it does on configuring individual preferences. Learning this made me wonder what exactly it is that people mean when the say that Firefox has a lack of support for Active Directory. Do they mean using Active Directory to manage install and updates? Or do they mean the types of customization that are provided via IE’s Group Policy.
So I’d like to pose a few questions to my readers:
- Do you use Active Directory and Group Policy to manage Internet Explorer? If so, what policies are most important to you?
- Do you use FirefoxADM or WetDog to manage Firefox? If so, what features are most important to you?
- If support for Group Policies was implemented for Firefox, should it focus more on customizing the browser or setting preferences?
For more information on this subject, here are some links:
- Overview of Internet Explorer Group Policies
- Microsoft Spreadsheet where we removed everything but the IE policies.
- Bug 337679 (cck could allow settings to be set via windows group policy)
- Bug 267888 (Windows 2000/XP/2003 Group Policies support (make firefox configurable with domain group policy objects))
(*) By customizing the browser I mean things like removing printing, removing the help menu, removing view source, removing the context menu, preventing saving files to disk, removing the ability to open new windows, turning off tabbed browing, removing access to bookmarks, etc.
Before we get started on this next topic, I need to make one correction. In earlier posts, I said to use
collapsed="true" to hide XUL menuitems. A better option is to use
hidden="true" instead. Using collapsed doesn’t hide the margins, so you get a lot of whitespace in your menus.
I also mentioned customizing the toolbar in my last post. We’ll actually save that for a future post.
Now that we’ve seen how to create XUL overlays to modify menus, let’s try out a real world scenario to see what else we might need to do. Let’s say we want to remove the user’s access to “Full Screen” mode. (I have no idea why you would ever want to do this, but Microsoft provides it as a customization in their group policy, so someone must want it.) Removing the menu is the easy part. We look in the file browser-menubar.inc and see that the ID of the menu is fullScreenItem. So by adding this code to our overlay:
we make the menu go away.
But we have a problem. The user could also press F11 to use “Full Screen” mode. How do we stop that? Luckily key commands are also defined in XUL, so we can modify those. Most key commands are defined in the file browser-sets.inc. Searching through this file, we find:
<key id="key_fullScreen" keycode="VK_F11" command="View:FullScreen"/>
By simply adding this line to our overlay:
<key id="key_fullScreen" command=""/>
we prevent the keystroke from working.
That was an easy one. Let’s try something harder. Let’s remove access to “View Source.” View Source can be accessed three different ways, the View menu, the keystroke Ctrl+U, and View Page Source on the page’s context menu. Let’s remove all three. We already learned how to remove the keystroke:
What about the context menu? Removing items from the context menu can be done exactly the same way as removing items from any other menu – with hidden. The question is where do we get the IDs for items on the context menu. Similar to the main main and they keystrokes, it is stored it its own file, browser-context.inc. Here we see that the ID for the view source item on the context menu is context-viewsource so we can just add
<menuitem id="context-viewsource" hidden="true">
to our overlay. OK, one last thing. Let’s remove the actual View Source menuitem. Looking in browser-menubar.inc we see:
<menuitem accesskey="&pageSourceCmd.accesskey;" label="&pageSourceCmd.label;" key="key_viewSource" command="View:PageSource"/>
So now you should have most of the tools in your toolbox to remove functionality from the Firefox menus using the CCK to create the XUL overlay.
Now that we know where to add our XUL changes in a CCK XPI, let’s take a look at what we can change. You’ll remember from the previous post, we added this line:
and we were able to disable the Options… menuitem. The obvious questions then are, what else can I do and how do I find out what things I can change.
First let’s talk about what you can change. It’s beyond the scope of this article to go into all the things you can change with XUL. If you want to learn more about XUL, you can check out XULPlanet. For enterprise customization, there are probably two main things we would want to do: disable something or make it go away. We already know how to do disabling, but how would we make the Options… menuitem go away? The answer is the collapsed attribute:
This will make the menuitem go away completely.
OK, so we know how to change the XUL, let’s find out what we can change. You’ll notice that in order to change the menuitem, we needed to know the ID of the menuitem. So how can we find the ID of what we want to change? For this, we need to understand a little more about how the Firefox UI works. Most of the main Firefox window’s UI is contained in a file called browser.xul. By looking through this file, we can find various parts of the UI and use our knowledge of overlays to change them. For instance, looking through that file, we find out that the ID of the toolbar is toolbar-menubar. So if we wanted to make the menu go away, we could simply add:
Note that not only did we need to use the ID, but we had to use the name of the tag (toolbar) as well. You’ll notice that the menu is not in browser.xul (you won’t find menu_preferences, for instance). This is because the menu is contained in a separate file called browser-menubar.inc. You can consider this file to be a part of browser.xul for our purposes.
If you’re having trouble finding some UI in the XUL file, try this. Go to the Mozilla 1.8 Cross-Reference and search on the text you are trying to find. For instance, we’ll search on “Error Console.” This will return a DTD file that contains the string for the menu item (we want the one that begins with browser). On the same line as the text, you’ll see an identifier that usually ends in label. For the error console, it’s
By searching on the label, we can find the exact place where it is used in Firefox. In this case, it points us to browser-menubar.inc. We can use the information there to create an overlay that disables or removes the Error Console menuitem.
In the next installment, we’ll learn how to customize the default buttons on the toolbar.
Computerworld has an article out today about Firefox in the enterprise that contains some quotes from me. There’s also some slashdot discussion, but most of that seems to be from people who don’t really understand enterprise requirements.
Unfortunately I didn’t respond quickly enough to the request for information, so my stuff is kind of tacked on to the end. Here’s the key message I wanted to get across (which wasn’t in the article):
The main thing we think has changed at this point is that we (IBM) are working with the Mozilla Community to try to get the community more interested in the enterprise things. In particular, we (the community, as well as IBM) want to help enterprises with customization and deployment of Firefox, as well as work to figure out what can make Firefox better for the enterprise.
I agree with the overall article though. More needs to be done to make Firefox enterprise ready. Hopefully anyone who wants to help with that effort will participate using the various avenues we have created.
Now that we know the basics of XUL Overlays, we’re going to look at using an existing CCK XPI to make our changes. The reason we’re using the CCK XPI is because we want to take advantage of code that has already been written for us. We’ll start by examining the contents of an XPI created by the CCK Wizard. Note that for this example, we’ve used the CCK Wizard to create an XPI that has no customization at all. We’re just going to add our new modifications.
After creating an XPI using the CCK Wizard, copy unzip that XPI into a directory. You’ll see the following files:
chrome/cck.jar components/cckService.js defaults/preferences/firefox-cck.js chrome.manifest install.rdf install.js cck.config
The two files that are important to us are chrome.manifest and cck.jar. Here’s that the manifest file looks like:
overlay chrome://browser/content/browser.xul chrome://cck/content/cck-browser-overlay.xul style chrome://global/content/config.xul chrome://cck/content/cck-config.css content cck jar:chrome/cck.jar!/content/cck/
This file defines the overlays we talked about earlier. We are overlaying a file called cck-browser-overlay.xul onto the regular browser XUL file and we are overlaying a new CSS file. We won’t modify the manifest right now since it has exactly what we need. Later we’ll need to make changes when we want to anything other than the main browser UI.
The next file that is important to us is cck.jar. This is a ZIP file that contains the XUL overlay files. After unzipping this file, you’ll see cck-browser-overlay.xul. This is the file where we are going to make our modifications. For now, lets do something similar. Edit the file cck-browser-overlay.xul and add this line before the <stringbundleset> section (we’ll get into the specifics of this change in the next installment).
<menuitem id="menu_preferences" disabled="true"/>
Once you’ve made this change, zip the JAR first and then zip the XPI file. Next, install the XPI.
If everything worked correctly, when you look at the Tools menu, the Options… menuitem should be disabled.
What we’ve seen in this installment is that by modifying an existing CCK XPI, we can start customizing the Firefox UI. We didn’t have to write our own extension from scratch. In our next installment, we’ll look at the interesting things we can do in our browser overlay.
We’ve recently created a newsgroup/mailing list to talk about Firefox as it relates to enterprise, educational institutions, or other similar ventures. Here’s the first post I just put up:
The goal of this newsgroup is to help enterprises, educational institutions and other similar groups embrace Firefox.
When we use the term “enterprise,” we in no way mean to limit the focus to large businesses. We want to help anyone from high schools to Fortune 100 companies.
We’ll be talking about issues related to things like:
* Customizing the browser for a particular deployment
* Deploying the browser in a specific environment
* Creating custom extensions for your deployment
* Training issues
We have a wiki with some information at:
There have also been some posts on my blog:
We look forward to your participation!
You can access the newsgroup multiple ways:
- mozilla.community.enterprise on news.mozilla.org
- mozilla.community.enterprise on Google Groups
- mozilla.community.enterprise mailing list
Hopefully we can use this medium to foster some more discussion around Firefox in the enterprise.
I get asked a lot of questions about customizing Firefox that are beyond the scope of the CCK. Most of these questions involve how to prevent users from doing certain things or hide certain options in the UI. My typical answer is “you can write an extension for that,” but most people don’t want to go through the hassle of figuring out how to write an extension for what in most cases is a very simple change.
To try to address these issues, I’m going to do a series where I answer questions related to making simple changes to Firefox that might be needed in an enterprise environment. My goal is that a person with no extension experience at all will be able to make these changes by simply modifying an existing CCK extension.
Before I get into the specific customizations, I’m going to start with a very high level view of how we are going to make these changes.
There are currently two changes that the CCK makes using XUL overlays – adding a menu item to the Help menu and chanding the icon, link and tool tip for the animated icon (sometimes called the throbber). Both of these involve knowing the ID of the item you want to modify and then writing XUL that either modifies or replaces the existing XUL.
Here’s the XUL Overlay for adding the Help menu item:
<menupopup id="menu_HelpPopup"> <menuseparator insertafter="aboutSeparator"/> <menuitem label="Our New Help Item" insertafter="aboutSeparator" accesskey="o" oncommand="openUILink('http://example.com'), event, false, true);" onclick="checkForMiddleClick(this, event);"/> </menupopup>
In this case, we needed two IDs – the ID of the help menu (menu_HelpPopup) and the id of the item after which we want to insert our menu (aboutSeparator). What this overlay says is “in the menupopup with an ID of menu_HelpPopup, insert a new separator after the exisiting item aboutSeparator, then insert a new menuitem after that old separator as well.” Don’t worry about the different attributes – we’ll cover those later.
We can also use a XUL overlay to replace content. Here’s the overlay for the animated icon:
<button id="navigator-throbber" oncommand="openUILink('http://example.com')" onclick="checkForMiddleClick(this, event);" tooltiptext="TOOLTIP" disabled="false"/>
In this case, we needed the id of the existing animated icon (navigator-throbber) and we used our XUL to actually change the animated icon. We changed it from being disabled, we added tooltip text, and we added functionality when it is clicked.
Now that you have a very basic sense of how XUL overlays work, next we’re going to take a look at where in an existing CCK XPI our new overlays are going to be placed.
It’s been one year since I released Operator and I wanted to take the opportunity to thank everyone who is using it and has had good things to say about it. I haven’t advanced the technology as much as I wanted to over the past year but hopefully this next year we’ll see much more, especially with the inclusion of a microformats API in Firefox 3.
And now for something completely different.
If you use Operator on amazon.com, you might notice that the “Tagspaces” item is available, but when you pop it down, you get a lot of stuff that says “ref=tag_dpp_cust_itdp_t.” This is because amazon (like a lot of other sites – any drupal site comes to mind) is not following the rel-tag spec. To attempt to work around this problem, I’ve added a hidden preference to Operator called “extensions.operator.allowInvalidTags.” If you add this preference via about:config and set it to true, Operator will display the text content of the tag and use it, instead of the proper tag value. Note that although this makes some things work on amazon.com, they still is completely clueless about how to use rel-tag – checkout their Firefox tag page and take a look at the Tagspaces menu with the hidden preference turned on. You’ll get things like “See all 226 tags” and “See all 25 customers.” Great job amazon! Go read the spec!
And for everyone else that has screwed up tags, please go read the spec. If you don’t like the spec, that’s fine, but please don’t add rel=”tag” to anything that is an invalid tag.
I’m making available a beta of Operator 0.9, which has support for Firefox 3 and uses the built-in Firefox 3 microformats support.
The primary focus of this release has been performance, and I believe it shows. Sites like the Samsonite Store Locator are MUCH faster. Note that if you want to improve performance even more, you should remove the adr microformat from your toolbar. I’ve done this for new installs of Operator in the future. Since most pages with adrs have them in hCards, I’ve moved all the functionality that was for adrs into the hCard submenus.
Other changes include support for whether or not hidden microformats are displayed. You can try this out on the Samsonite website. Note that this functionality doesn’t work on Firefox 3 because it required a change to the core Microformats support which hasn’t made it into Firefox 3 yet.
Other small changes are the addition of searching for tags on amazon.com products, as well as searching for addresses on MapQuest.
One thing that is NOT in this release is modifications to support the new RDFa spec. We’re still waiting for some stuff to be finalized for that.