My Best Year Ever

As 2015 comes to an end, it’s time to reflect back on the accomplishments of the previous year. For me personally and for Kaply Consulting, it was my best year ever.

  • I contributed more patches to Mozilla than I have in many years.
  • I grew my email list substantially.
  • I grew my business revenue by 10%.
  • I finally planned well enough to be able to take the last two weeks of the year off.

The major contributor to my success this year, was Michael Hyatt’s Five Days to Your Best Year Ever. If you’ve struggled in the past with goal setting, I highly recommend checking out his program. You can start with this free video.

Thank you to everyone who helped me have such a great year. Happy holidays and happy new year!

Disclaimer: I’m an affiliate partner, so if you click and purchase the program, I will receive an affiliate commission.

Identifying Preferences Names in Firefox

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.

Windows 10, Permission Manager and more

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.

Firefox 44 has some major changes coming to JavaScript let/const behavior that could impact your AutoConfig file. I’ll be making sure the CCK2 is compatible, but you should make sure you’re testing with the latest Firefox 44. Obviously this will impact the Firefox 45 ESR as well, so you’ll want to do lots of testing there.

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.

Using Hidden UI in the CCK2

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 menuitem.viewCustomizeToolbar.)

    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…

My Take on WebExtensions

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.

Firefox 40 Breaking Changes for Enterprise

There are couple changes in Firefox 40 that folks need to be aware of. One I’ve mentioned, one I just found out about.

  1. 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.
  2. 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.

Domain Specific Flash Enabling on Firefox

Update: It looks like Flash has been updated to, 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 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.

The End of Firefox 31 ESR

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.

CCK2 2.1(.1) is Officially Available

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, 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.

Final (Hopefully) Beta of CCK2 2.1 Available

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
  • Heartbeat

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, 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