Plugin Support in Firefox 52

Last year, Mozilla announced that support for NPAPI plugins (except for Flash) would be ending in March 2017. That date is approaching fast, so I wanted to give folks more information about what’s happening. If you subscribe to my newsletter, this is the same information I gave there.

In short, Firefox 51 (which was released last week) is the last release of mainline Firefox that will support NPAPI plugins (except for Flash). Starting with Firefox 52, the only version of Firefox that will support plugins is the ESR. Firefox 52 WILL NOT have plugin support (except for Flash). Firefox 52 ESR WILL have plugin support.

That means that if your users are currently on Firefox 51 and you need plugin support, you need to switch Firefox so that it gets updates from the ESR channel. To do this, you need to change two files, channel-prefs.js and update-settings.ini.

In defaults/prefs/channel-prefs.js, change:

pref("", "release");


pref("", "esr");

In update-settings.ini, change:




It is important that you make this change as close as possible to the release of Firefox 52 ESR (March 7, 2017), otherwise security updates to Firefox 51 will not be applied.

Plugin support will continue in the 52 ESR line only, meaning Firefox 59 will not have plugin support.

Some folks may ask why both Mozilla didn’t wait until Firefox 53 to deprecate plugins so that both versions of Firefox 52 would have the same capabilities. If they had done that, users who needed plugins would have had to downgrade to Firefox 52 ESR and that could cause incompatibilities with profiles. It made more sense to encourage people to switch to the same version (52 to 52 ESR).

CCK2 Switching to Lifetime Support

Effective immediately, I am switching CCK2 support from a subscription to a single purchase for lifetime support. I am also raising the price to $999 USD effective February 1, 2017.

Anyone with an active subscription on January 31, 2017 will be automatically upgraded to lifetime support.

What exactly does lifetime support mean?
My goal is to support the CCK2 as long as is practically possible, and I believe that will be for at least the next couple years.

Why am I making this change?
When I originally setup the CCK2 support subscription, I intended it to be recurring income for my consulting business. That didn’t really happen. There wasn’t enough consistent income to make a large impact and I spent a great deal of time chasing down renewals (many of which didn’t happen). The best use of my time and energy is working on the CCK2, not trying to get folks to renew.

Will the level of support be changing?
At this time, there will be no changes to the level of support as indicated here.

Does this mean you are reducing your commitment to the CCK2?
Quite the contrary, it will allow more focus more on the development side of the CCK2 instead of the business side.

How can I purchase CCK2 Lifetime Support?
If you want to purchase CCK2 support at the current price ($499 USD), you can use the button below or click here.

Thank you for your continued support.

Keyword Search is No Longer Feeling Lucky

UPDATE: I put a hack in into Keyword Search that automatically clicks on the first result if you are using “I’m feeling lucky.” This is the best I can do for now.

I’m getting a lot of reports that the Google “I’m Feeling Lucky” option is no longer working with Keyword Search. Unfortunately Google seems to have broken this in their latest search update even though they’ve left the button on the homepage. There’s nothing I can really do to work around it at this time.

If you want a similar feature, you can switch to DuckDuckGo and use their “I’m Feeling Ducky” option.

Debugging Firefox AutoConfig Problems

I get a lot of questions about debugging AutoConfig issues, so I thought I would document what I do to try to track them down.

If Firefox starts, go to about:config and search for general.config. Make sure there are values for general.config.filename and general.config.obscure_value. If they are not there, your defaults/prefs/autoconfig.js file is not being read. The most common reason this happens is permissions or you’ve placed it in the wrong directory.

If both the general.config values are present, the next step is to check if your cfg file is being read. I usually make a very simple cfg file:

// First line is always a comment
lockPref("a.b.c.d", "e.f.g.h");

Then I go to about:config and verify that the a.b.c.d preference is there (it will be at the top). If the preference is not there, then something must be very wrong. I check the browser console to see if there are any errors. If the preference is there, AutoConfig is working correctly. I then start adding it the parts of my AutoConfig file a piece at a time, leaving the setting of the a.b.c.d pref at the end of the file. Then I check about:config each time and see which line is breaking the AutoConfig file.

If the browser doesn’t start at all, the first thing I do is put all my AutoConfig code in a try/catch block like this:

// First line is always a comment
try {
  // My AutoConfig code.
} catch (e) {

If the browser then starts, I look in the browser console to see what the error was. If the browser still doesn’t start, I start removing pieces of my AutoConfig until it does.

The most common problem in the past with AutoConfig was the use of let instead of var. This was fixed in Firefox 42 and should no longer be an issue. Some other common problems were around the use of international characters, in particular saving AutoConfig files as UTF-8 versus ASCII. This should also be fixed. All AutoConfig files should be saved as UTF-8.

In general, as long as you don’t have JavaScript syntax errors in your AutoConfig file, they should just work. That’s been my experience, and I’ve written some pretty complicated AutoConfig files.

Upcoming Changes to Root Certificates in Firefox on Windows

For organizations interested in supporting Firefox on Windows in a managed environment, a longstanding hurdle has been that Firefox does not use the underlying platform’s certificate database when verifying TLS web server certificates. As an organization, having a separate transparent and open certificate authority program furthers Mozilla’s goal of fostering the open web. However, for users in managed environments attempting to connect to services that use non-public certificate hierarchies, this often results in a sub-optimal experience where Firefox will not connect while other browsers will.

To address this shortcoming, we have been developing an optional feature that, when enabled, will search the Windows certificate trust store for certificate authorities that have been added by the user or an administrator. If Firefox encounters any such CAs that are trusted to issue TLS web server certificates, it will incorporate those CAs into its own path building logic. When verifying a server certificate, if Firefox can find a path to one of those imported roots, the connection will succeed.

This feature is available in Firefox 49 and up (currently in beta). To give it a try, go to about:config and add the boolean preference security.enterprise_roots.enabled and set it to true. After that, Firefox should connect successfully to sites using certificates issued by 3rd party root certificates that have been added to the Windows trust database. Note that currently these root certificates will not appear in Firefox’s certificate manager as they are intended to be managed from the interfaces provided by Windows itself. This may change in the future.

But wait – there’s more! Using the same infrastructure, we have developed a similar feature to handle the case where Firefox is being used on an account that is being monitored by the Microsoft Family Safety functionality in Windows 8.1. For background information, this involves a local intercepting proxy that can log and/or block web traffic to and from an account. A similar feature existed briefly in Windows 10 but was reconfigured to only affect Edge. Starting with version 50, instead of showing the untrusted connection error page Firefox should “just work”.

These features are still in the early stages, so if you encounter any unexpected behavior, please feel free to file a bug.

This has been a guest post from David Keeler, Mozilla Engineer.

First Beta of e10s CCK2 is Available

The first version of the CCK2 Wizard that supports e10s is available. This is not production ready, so please don’t use it for production.

You can download it here.

It has full backwards compatibility to Firefox 31, so you don’t need to use different CCK2 Wizards for older Firefox versions. Assuming there are no major bug reports, this will be released officially at the end of the week.

Please report bugs on Github. Support issues go to

Default Profile Directory Doesn’t Work in Firefox 46

It was recently discovered that support for using the defaults/profile directory to prepopulate a Firefox profile was removed in Firefox 46.

Here’s an AutoConfig file that adds back the functionality:

const {classes: Cc, interfaces: Ci, utils: Cu} = Components;

if (!Services.prefs.prefHasUserValue("browser.startup.homepage_override.mstone")) {
  // New profile
  var defaultProfileDir = Services.dirsvc.get("GreD", Ci.nsIFile);
  if (defaultProfileDir.exists()) {
    var profileDir = Services.dirsvc.get("ProfD", Ci.nsIFile);
    try {
      copyDir(defaultProfileDir, profileDir);
    } catch (e) {

function copyDir(aOriginal, aDestination) {
  var enumerator = aOriginal.directoryEntries;
  while (enumerator.hasMoreElements()) {
    var file = enumerator.getNext().QueryInterface(Components.interfaces.nsIFile);
    if (file.isDirectory()) {
      var subdir = aDestination.clone();
      try {
        subdir.create(Ci.nsIFile.DIRECTORY_TYPE, FileUtils.PERMS_DIRECTORY);
        copyDir(file, subdir);
      } catch (e) {
    } else {
      try {
        file.copyTo(aDestination, null);
      } catch (e) {

This should work for most file types, although it probably won’t work for bookmarks.html

I’ll also be adding this functionality to the next version of the CCK2 which will be released later today.

Broken Add-ons in Firefox 46

A lot of add-ons are being broken by a subtle change in Firefox 46, in particular the removal of legacy array/generator comprehension.

Most of these add-ons (including mine) did not use array comprehension intentionally, but they copied some code from this page on for doing an md5 hash of a string. It looked like this:

var s = [toHexString(hash.charCodeAt(i)) for (i in hash)].join("");

You should search through your source code for toHexString and make sure you aren’t using this. MDN was updated in January to fix this. Here’s what the new code looks like:

var s = Array.from(hash, (c, i) => toHexString(hash.charCodeAt(i))).join("");

The new code will only work in Firefox 32 and beyond. If for some reason you need an older version, you can go through the history of the page to find the array based version.

Using this old code will cause a syntax error, so it will cause much more breakage than you realize. You’ll want to get it fixed sooner than later because Firefox 46 started rolling out yesterday.

As a side note, Giorgio Maone caught this in January, but unfortunately all that was updated was the MDN page.

CCK2 Source on GitHub (and a new release)

I had put the original CCK Wizard on, but since I did the development of the CCK2 on my private SVN, I had never gone through the trouble of making the source available. It is technically open source, but I wasn’t doing enough to allow other people to contribute to the code. That changes today.

The CCK2 source is now available on GitHub under the MPL.

Nothing else about how I manage the CCK2 will change – I will still be using Freshdesk for support requests and I will still have premium support subscriptions. I will be using GitHub issues only for actual bugs in the CCK2.

When I do new releases of the CCK2, you’ll be able to get information about those releases on the releases page.

And speaking of new releases, I’ve just updated the CCK2 to fix a bug related to adding bookmarks with international characters. You can download it here.

Time For a (Job) Change

I’ve always been passionate about Firefox in the enterprise. When I started Kaply Consulting eight years ago, I had always hoped that my primary work would be around enterprise Firefox. Unfortunately, that never really happened; enterprise work is less than 5% of what I do. So I do a lot of other work to support the things that I’m most passionate about. As those obligations have become bigger and bigger, I’ve found less and less time to work on the CCK2 and other enterprise related projects which I believe are important to the future of Firefox.

At the same time, with the changes coming to the way extensions are done in Mozilla, I even wondered if I wanted to continue doing what I do. After watching a video of myself (skip to 6:30) speaking about Mozilla 11 years ago, I came to the conclusion that Mozilla is in my blood. Heck, I’ve been doing this stuff since before Mozilla even existed (can you say Netscape 2.0.2?)

Combined with the increasing costs of being self employed and the increasing needs of my family, I’ve decided the best way forward for me and my family is to become a company man again.

And what better company to work for then…


Yes, after years of working ON Mozilla, I’m finally working FOR Mozilla.

And I’m quite excited about the opportunity. I’ll be working on the partner distribution team at Mozilla.

I will continue to do enterprise work on the side as long as it doesn’t conflict with any of my Mozilla work, so there’s no need to worry about that. And since I won’t have to juggle as many things, I should have more free time to work on the CCK2.

TL;DR – I’m going to work for Mozilla. Kaply Consulting will still do CCK2 and enterprise.