One question I get a lot is how to associate a preference option that you see in the Firefox preferences with the name of a preference to set or lock.
To make getting that information easier, I’ve made a very simple extension called Pref Helper that when installed highlights any item that has a corresponding preference in blue and shows that preference when you right click on the item. This should make it easy to find the preference name you are looking for.
Then you can set or lock it with the CCK2.
You can download it here.
There are some changes coming to Firefox that might impact enterprise users, so i wanted to make folks aware of them.
Firefox 42 has a change to the permission manager so that permissions are based on the origin not just the host. This means that code like this in your AutoConfig file:
Services.perms.add(NetUtil.newURI("http://" + hostname), ...
will only apply to http. You need to be explicit with both:
Services.perms.add(NetUtil.newURI("http://" + hostname), ...
Services.perms.add(NetUtil.newURI("https://" + hostname), ...
Existing permissions will be migrated to both http and https. I’ve updated the CCK2 to account for this, but you’ll need to rebuild your distribution.
Finally, I got a question about the Firefox/Windows 10 page appearing even when you have upgrade pages turned off. Unfortunately this page bypasses the existing upgrade code. To make sure it doesn’t appear, set the preference browser.usedOnWindows10 to true.
One of the questions I get asked the most is how to hide certain UI elements of Firefox. I implemented the Hidden UI feature of the CCK2 specifically to address this problem. Using it can be a little daunting, though, so I wanted to take some time to give folks the basics.
The Hidden UI feature relies on CSS selectors. We can use CSS Selectors to specify any element in the Firefox user interface and then that element will be hidden. The trick is figuring out the selectors. To accomplish this, my primary tool is the DOM Inspector. With the DOM Inspector, I can look at any element in the Firefox user interface and determine it’s ID. Once I have it’s ID, I can usually specify the CSS selector as
#ID and I can hide that element. Let’s walk through using the DOM Inspector to figure out the ID of the home button.
- Install the DOM Inspector
- Go to Developer Tools and select DOM Inspector
- From the DOM Inspector Window, select File->Inspect Chrome Document and select the first window
- In the DOM Inspector Window, click on the Node Finder.
- Click on the Home button in the Firefox Window.
- You’ll see results in the DOM Inspector that look like this:
This gives us something unique we can use – an ID. So
#home-button in Hidden UI will hide the home button.
You can use this method for just about every aspect of the Firefox UI except for menus and the Australis panel. For these items, I turn to the Firefox source code.
If you want to hide anything on the Australis panel, you can look for IDs here. If you want to hide anything on the Firefox context menu, you can look here. If you want to hide anything in the menu bar, you can look here.
As a last resort, you can simply hide menuitems based on their text. For instance, if you wanted to hide the Customize menu that appears when you right click on a toolbar, you could specify a selector of
menuitem[label^='Customize]. This says “Hide any menu item that begins with the word Customize.” Don’t try to include the ellipsis in your selector because in most cases it’s not …, it’s the unicode ellipsis (…). (Incidentally, that menu is defined here, along with the rest of the toolbar popup menu. Because it doesn’t have an ID, you’ll have to use
Hopefully this should get everyone started. If there’s something you can’t figure out how to hide, let me know. And if you’re trying to hide everything, you should probably be looking at a kiosk solution, not the CCK2…
Let me start out by saying that I understand the need for something like WebExtensions. A cross browser extension API will be a great thing for the future of browsers. I understand why Mozilla is doing it. What I take issue with is the belief that existing Firefox only add-on developers will jump at the opportunity to use this new API. As far as I’m concerned, the only add-on developers that will benefit from this new API are Chrome developers who will find it much easier to port their extensions to Firefox.
Most Firefox extension developers do it as a hobby. Typically they have an itch about something in Firefox and that write an extension to scratch it. Then they make that extension available to everyone. Over time we all build up a set of extensions that make Firefox behave the way we (and clearly other people) want it to. (Chris Finke is a great example of this.) Every so often something changes in Firefox that breaks one of our extensions. At that point we have to make a decision; it it worth the time and energy to keep this extension going. Sometimes we keep it going, sometimes we give up (hence the ton of dead extensions on AMO). Luckily most of the time Firefox changes don’t break all our extensions, so we usually can keep going. With e10s coming up though, lots of developers have had to make decisions as to whether or not it is worth it to rewrite and some developers have gone through that pain (and it is pain – a lot of pain).
Now developers are being told in the next one to two years they will have to completely rewrite ALL of their add-ons. What are the odds that these hobby add-on developers are going to do that?
Let’s be honest. Availability of APIs isn’t the difficult part of the discussion. Availability of time and energy to even attempt to rewrite all of our add-ons is the problem. And when you add in the fact that Mozilla hasn’t given add-on developers the marketplace we’ve been promised for years (which Chrome has had since day one), you’ll end up with a lot of developers deciding that it’s simply not worth it.
But let’s talk availability of APIs. I’ll use two of my extensions as examples. Keyword Search accesses the wrappedJSObject of search submissions in order to manipulate the submission. Will there really be an API for that? Or what about the CCK2? Will there really be APIs that allow me to modify the built-in preferences pages including removing pages or controls? Or what about disabling private browsing? Or removing sync? Or removing access to about:config? I doubt it. There are just too many things that extensions do (most of them pretty obscure) to be able to provide an complete API.
I’ll watch what goes on and hope that I’m wrong, but I’m not very optimistic.
I will say this, though. It’s a great day to be a Chrome developer.
There are couple changes in Firefox 40 that folks need to be aware of. One I’ve mentioned, one I just found out about.
- The distribution/bundles directory is no longer used. As I said in this post, you must get the latest CCK2 and rebuild your AutoConfig distribution for use on Firefox 40. The new distribution you build will work as far back as Firefox 31. Unfortunately, the ability to disable safe mode won’t work on Firefox 40 and beyond.
- The searchplugins directory is no longer in browser/searchplugins; it’s integrated into the the product. If you were using this directory to add or remove engines, it won’t work. You can either use the CCK2 or put the engine XML files in distribution/searchplugins/common. See this post.
If you have additional problems, please let me know.
Update: It looks like Flash has been updated to 22.214.171.124, so this workaround shouldn’t be needed. Save it for a rainy day (or the next time Firefox blocklists Flash.)
This big news today is that Mozilla blocked version 126.96.36.199 of Flash because of security vulnerabilities. At the time they blocked it, it was the latest version of Flash available. While this might be great for users, there are enterprises that have mission critical apps that require Flash.
Although you can use the various notifications in Firefox to re-enable Flash (it’s what Firefox calls a soft block), you might wonder how you can make sure Flash is enabled for the specific domains you need it on regardless of the status of Flash security. You can do that using the Firefox permissions manager.
The easiest way to do this is using the CCK2. When you enable all plugins for a domain on the permissions page, it makes sure that Flash and Java work on that domain even if they are vulnerable.
If you are using AutoConfig, you can add this code to your config file:
Services.perms.add(NetUtil.newURI("http://some.domain"), "plugine:flash", 1);
Services.perms.add(NetUtil.newURI("http://some.domain"), "plugin-vulnerable:flash", 1);
This will make sure that flash always works on the given domain. If you want to do this inside of your browser, you can check out the Scratchpad.
Note that for security reasons, you shouldn’t enable the vulnerable versions of Flash and Java for any domain that you don’t have control over.
With the release of Firefox 39 today also comes the final release of the Firefox 31 ESR (barring any security updates in the next six weeks).
That means you have six weeks to manage your switch over to the Firefox 38 ESR.
If you’ve been wondering if you should use the ESR instead of keeping up with current Firefox releases, now might be a good time to switch. That’s because there are a couple features coming in the Firefox mainline that might affect you. These include the removal of the distribution/bundles directory as well as the requirement for all add-ons to be signed by Mozilla.
It’s much easier going from Firefox 38 to the Firefox 38 ESR then going from Firefox 39 to the Firefox 38 ESR.
If you want to continue on the Firefox mainline, you can use the CCK2 to bring back some of the distribution/bundles functionality, but I won’t be able to do anything about the signing requirement.
I announced and released CCK2 2.1 to my mailing list subscribers last week. A couple bugs were found and fixed, and so I am officially releasing CCK 2.1.1 to the world and making it available as an update to CCK 2.0 users. You can download it here.
This new CCK2 represents a major change over previous versions in that it no longer depends on the distribution/bundles directory when using AutoConfig. It creates its own directory (cck2) that should be preserved across Firefox installs. I made this change in anticipation of Firefox 40 where the distribution/bundles directory will no longer work. For people that were using the distribution/bundles directory to distribute their own add-ons, I’ve enabled the cck2/bundles directory to serve the same purpose. As with the distribution/bundles directory, add-ons built with the SDK and restartless add-ons will not work.
Other changes in this new version include the ability to disable various new Firefox features like Pocket and Social Sharing.
I’ve also made a change to the export function that should make it easier to move CCK2 configs to other machines. If you’ve placed your resources (search plugins, certs, etc.) under your output directory, when you export your config, it will use relative paths. After transferring all the data to the new machine, you can edit the JSON file to change to the new output directory before importing.
As always, the CCK2 Wizard is provided as-is. You can open issues and feature requests, as well as participate in forum discussions at cck2.freshdesk.com, but the only way to guarantee responses is to purchase a CCK2 Support plan.
I really appreciate the support of the folks who have done that.
Beta 6 of CCK2 2.1 is available here.
This version includes the ability to turn off the following features:
- Firefox Marketplace
- Firefox Hello
- Social Sharing
- The Forget Button
Also, for AutoConfig only, it adds the ability to to install extensions that previously used to work in the distribution/bundles directory.
To use this feature, after unzipping the autoconfig.zip, create a bundles directory under the cck2 directory and place any directories there the same way you placed them in distribution/bundles.
This feature is experimental, but in my testing, it worked for most things. It will not allow you to disable safe mode, though. This only works for extensions that worked in distribution/bundles, so it does NOT work for restartless extensions.
I’d appreciate any help testing. Please report any problems you have at cck2.freshdesk.com.
Bug 1144127 was checked in. This means that starting in Firefox 40, placing add-ons in the distribution/bundles directory will no longer work.
For many years I recommended distribution/bundles as the best place for enterprises to deploy non bootstrapped extensions. It allowed them to make their extensions a part of core Firefox and prevent users from removing them. Unfortunately adware/spyware folks started using this method as well, so we lost this ability. (This is why we can’t have nice things.)
So what does this mean going forward?
- You will no longer be able to disable safe mode. You can set the environment variable MOZ_DISABLE_SAFE_MODE_KEY to prevent using the startup shortcut or set MOZ_DISABLE_AUTO_SAFE_MODE to prevent crashes from starting safe mode, but a user will always be able to start Firefox in safe mode from the command line.
It’s much more difficult for you to prevent a user from disabling any extensions you need to add for your company. You’ll probably need to do something evil like hide them inside of the add-ons manager. You can contact me if you need code to do that.
AutoConfig now becomes the preferred method of doing pretty much any Firefox configuration (since you can’t place a custom extension into the distribution/bundles directory).
I’m actively working on making the CCK2 work without the distribution directory. The latest beta is here. Obviously some features will be lost st first. I hope to bring as many back as I can. It should be ready by the end of the week I hope.
As a side note, this means that many of my blog posts will have incorrect information. I’m still trying to figure out how to solve that going forward.