I did a presentation today at the Mac Admin and Developer Conference UK on configuring Firefox.
I’m making the slides available now, and will link to the video when it is available.
Also, here is a link to the demo AutoConfig file.
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.
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.
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.
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.
If you have additional problems, please let me know.
Update: It looks like Flash has been updated to 188.8.131.52, 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 184.108.40.206 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:
Components.utils.import("resource://gre/modules/Services.jsm"); Components.utils.import("resource://gre/modules/NetUtil.jsm"); 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.