Mozilla, money, microformats and more

Mozilla is currently doing a survey of Firefox enterprise users (and folks that might use Firefox in the enterprise if it had more stuff). If you haven’t already, please let Mozilla know your thoughts.

It’s time for the 2017 Firefox Enterprise Survey!

Firefox changes coming in 2017 have the potential to affect how you
customize and deploy Firefox and we want to make sure we know the impact.

Please take a minute to fill out this quick survey. It will help us decide how many people are affected and where we can make a difference.

The main thing I’ve done with this version is (hopefully) finally solved the duplicate bookmarks problem. I’ve done this via two changes.

If a bookmark being added exactly matches another bookmark in the same location, it is removed

I’ve added a new option to do the same thing if the title of the bookmark is the same (so you can change URLs).

Another new feature is the ability to prevent add-ons from being hidden or disabled based on their ID. You can add these IDs on the add-ons page in the CCK2 Wizard. To find out the ID of an add-on, you can unzip the add-on’s XPI file and look in the file install.rdf.

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("app.update.channel", "release");

to

pref("app.update.channel", "esr");

In update-settings.ini, change:

ACCEPTED_MAR_CHANNEL_IDS=firefox-mozilla-release

to

ACCEPTED_MAR_CHANNEL_IDS=firefox-mozilla-esr

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

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.

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.

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:

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.

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.

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.

NOTE: I updated this code on April 18, 2017 in an attempt to be more robust and not depend on Firefox preference. If you are using remote autoconfig, make sure this code is in your local autoconfig, not in the remote version. And the correct directory for the default profile is defaults/profile, not defaults/browser/profile.

Most of these add-ons (including mine) did not use array comprehension intentionally, but they copied some code from this page on developer.mozilla.org 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: