Mozilla has announced that Firefox is taking another step to becoming just like Chome. Put simply, Firefox is dropping its core technology XUL and XCOM and adopting Chrome add-ons in place of its own. 

On the face of it Mozilla's announcement of moving to a standard API for add-ons seems sensible. If all browsers supported the same Add-on API then we would only have to write one universal add-on and it would work on everything. This is the same Utopian dream that drives the rest of the web in the form of HTML, CSS, JavaScript and other standards. 

But things are more complicated when it comes to browser extensions. 
You could say that Firefox is important because of its extensions model. Firefox was built using web technologies from the very start. Its internals are based on XUL and XCOM, both of which are based on web standards.  XUL is close to HTML, which means that the Firefox UI is like a web page and Firefox extensions can interact with the page loaded in the browser and the browser UI in the same way and at a deep level. This has become known as the "permissive add-on" model, but it really was a great deal of the rationale for creating Firefox in the first place.

A Firefox extension can more or less hook into the internal workings of the browser to radically change the way it behaves. This has resulted in Firefox being something of a testbed and development environment for innovative extensions, and this is what is about to be taken away.

Of course on the downside such a close integration with the browser internals means that extensions can be fragile. It has been known for extensions to break because of code changes that should have had no effect. 

According to the Mozilla Addon-ons blog:

"In the most extreme cases, changes to the formatting of a method in Firefox can trigger problems caused by add-ons that modify our code via regular expressions. Add-ons can also cause Firefox to crash when they use APIs in unexpected ways." 

Apparently enough is enough and this blog post announces that XUL and XCOM are to be phased out in favor of a much less powerful API - WebExtensions. This is a JavaScript API that provides access to only those parts of the browser that are included in its calls. 

Mozilla's WebExtensions API is supposed to be compatible with Google's Blink API. The blog says:

"To this end, we are implementing a new, Blink-compatible API in Firefox called WebExtensions. Extension code written for Chrome, Opera, or, possibly in the future, Microsoft Edge will run in Firefox with few changes as a WebExtension."

Currently not all of the WebExtensions API is implemented. It is fairly clear that the chances of a Chrome add-on working with Firefox without some modifications is zero. What this means is that users aren't going to be able to replace old unsupported extensions with Chrome extensions unless they are supported and the programmer is willing to put some work in. 

What is even stranger about this non-compatible compatibility is that Mozilla acknowledges that the new API is too weak to support many of the existing addons. As a result it plans to implement Firefox-specific extras in the API and  lists the following:

• NoScript-type functionality. This would come in the form of extensions to webRequest and possibly contentSettings.
  
  
• Sidebars. Opera already supports sidebar functionality; Chrome may soon. We would like to be able to implement Tree Style Tabs or Vertical Tabs by hiding the tab strip and showing a tab sidebar.
  
  
• Toolbars. Firefox has a lot of existing toolbar add-ons.
  
  
• Better keyboard shortcut support. We'd like to support Vimperator-type functionality.
  
  
• Ability to add tabs to about:addons.
  
  
• Ability to modify the tab strip (Tab Mix Plus).
  
  
• Ability to take images of frames/tabs (like canvas.drawWindow)

This also gives you some idea how weak the existing API is. 

So we can port Chrome extensions to Firefox and then extend them so that they only work under Firefox. 

One additional good thing about changing the API is that it supports multi-process browsers. Until now Firefox has been a single-threaded browser and this has significant disadvantages. The Electrolysis project has been working to convert it so that each tab runs in tis own thread. However, this means that existing add-ons will mostly not work. New add-ons that make use of the WebExtensions API will work. 

Add to this the fact that starting with Firefox 42 all add-ons will have to be signed by Mozilla and you can see that the whole Firefox add-ons infrastructure and eco-system is about to be trashed - and hopefully rebuilt.

Firefox is losing ground to Chrome and to IE/Edge. Presumably these changes also have the advantage that Firefox might get all of the add-ons that Chrome has, even though Firefox's market share is down to 11%.

Currently many existing Firefox developers aren't happy about having to start over and some are simply going to give up on the browser after having the existing API dropped and access restricted. 

The timeline for all these changes is fairly rapid:

Signing of extensions starts with Firefox 41. although not enforced in September. Electrolysis, i.e. multithreading, is to be rolled out to end users in December. XUL/XCOM based add-ons will be phased out in 12 to 18 months.

There is also the hint that XUL/XCOM are going to be removed from Firefox completely, although this is going to take a lot longer. 

You can't help but notice a distinct chill in the air with respect to Firefox where there was once so much rosy glow. 

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info