Thursday, October 20, 2016
Firefox to gain support for Chrome Add ons And Lose XUL plugins
Firefox to gain support for Chrome Add ons And Lose XUL plugins
Mozilla’s Firefox web browser has undergone some major changes in recent years. Support for unsigned extensions is being phased out. Tabs have moved to the top of the screen and settings menus hide behind a button on the right side of the screen. Overall Firefox looks a lot more like Chrome than it used to.
Soon it’ll even be able to support Chrome add-ons and extensions. That’s kind of cool, right?
But Firefox will also phase out support for legacy plugins based on XUL… which is a bit less cool.
Mozilla has announced that it’s changing its approach to add-ons in several key ways.
The first is the introduction of a new API called WebExtensions which is mostly compatible with the tools developers use to create extensions for Chrome and Opera web browsers. This will make it possible for you to install existing Chrome extensions in a Firefox web browser. But just as importantly, it means developers will be able to create cross-platform extensions that will be able to run on different web browsers.
Second, as Mozilla moves to a multi-process version of Firefox (another feature that makes the browser act more like Chrome), developers will need to make sure that their plugins are compatible with the Electolysis multi-process system.
Next, as expected, Mozilla will require that most extensions be validated and signed… When Firefox 41 launches on September 21st, unsigned extensions will be turned off by default, but users will be able to disable signature enforcement. When Firefox 42 is released around 6 weeks later, there won’t be an option to run unsigned extensions… but you can get around this by installing nightly or developer edition versions of Firefox.
Finally, the Firefox team is phasing out support for XPCOM and XUL-based add-ons. Mozilla says this will make the browser more secure and more stable… and without making this change, the team would be unable to implement the Electrolysis mult-process architecture.
So within the next 18 months, Mozilla plans to kill off support for these legacy plugins while encouraging developers to re-write them using WebExtension API or the JetPack SDK. But Mozilla acknowledges that some existing plugins can’t be rewritten using those tools, because they rely on functionality that’s not included.
The goal is to add features to the WebExtension API in the next year and a half, but it’s possible that some existing plugins will never be able to make the transition since they rely on a “permissive” model that allowed for deep integration into the browser… and that’s exactly the sort of thing Mozilla is ruling out for future add-ons.
The developer of popular Firefox add-on DownThemAll, for example, says he’ll probably stop developing plugins if Mozilla eliminates support for XUL-based add-ons because the new tools don’t offer the same kind of flexibility as those that are being deprecated.
While Firefox continues to use a different web rendering engine that Google Chrome, it sounds like the browser won’t just look like Chrome in the future… it’ll act almost exactly like Google’s web browser thanks to support for multi-process architecture, support for Chrome-compatible add-ons, and a walled-garden approach that only allows users to install signed and validated plugins.
So I have to wonder, is there still much reason to use Mozilla’s web browser rather than Google’s?
Soon it’ll even be able to support Chrome add-ons and extensions. That’s kind of cool, right?
But Firefox will also phase out support for legacy plugins based on XUL… which is a bit less cool.
Mozilla has announced that it’s changing its approach to add-ons in several key ways.
The first is the introduction of a new API called WebExtensions which is mostly compatible with the tools developers use to create extensions for Chrome and Opera web browsers. This will make it possible for you to install existing Chrome extensions in a Firefox web browser. But just as importantly, it means developers will be able to create cross-platform extensions that will be able to run on different web browsers.
Second, as Mozilla moves to a multi-process version of Firefox (another feature that makes the browser act more like Chrome), developers will need to make sure that their plugins are compatible with the Electolysis multi-process system.
Next, as expected, Mozilla will require that most extensions be validated and signed… When Firefox 41 launches on September 21st, unsigned extensions will be turned off by default, but users will be able to disable signature enforcement. When Firefox 42 is released around 6 weeks later, there won’t be an option to run unsigned extensions… but you can get around this by installing nightly or developer edition versions of Firefox.
Finally, the Firefox team is phasing out support for XPCOM and XUL-based add-ons. Mozilla says this will make the browser more secure and more stable… and without making this change, the team would be unable to implement the Electrolysis mult-process architecture.
So within the next 18 months, Mozilla plans to kill off support for these legacy plugins while encouraging developers to re-write them using WebExtension API or the JetPack SDK. But Mozilla acknowledges that some existing plugins can’t be rewritten using those tools, because they rely on functionality that’s not included.
The goal is to add features to the WebExtension API in the next year and a half, but it’s possible that some existing plugins will never be able to make the transition since they rely on a “permissive” model that allowed for deep integration into the browser… and that’s exactly the sort of thing Mozilla is ruling out for future add-ons.
The developer of popular Firefox add-on DownThemAll, for example, says he’ll probably stop developing plugins if Mozilla eliminates support for XUL-based add-ons because the new tools don’t offer the same kind of flexibility as those that are being deprecated.
While Firefox continues to use a different web rendering engine that Google Chrome, it sounds like the browser won’t just look like Chrome in the future… it’ll act almost exactly like Google’s web browser thanks to support for multi-process architecture, support for Chrome-compatible add-ons, and a walled-garden approach that only allows users to install signed and validated plugins.
So I have to wonder, is there still much reason to use Mozilla’s web browser rather than Google’s?
Available link for download
