Extension compatibility and Pale Moon
Posted: 2016-02-29, 09:27
Since there have been a number of questions (and complaints, and less-than-nice messages at my address) about extensions breaking in Pale Moon with updates, I'll try to explain here what the main reasons are. There are a number of different situations available.
First and foremost, people have to understand one thing above all else: Pale Moon is not Firefox!
I need to stress this because a lot of people still seem to think they are one and the same.
This is not a problem in Pale Moon. We have our own development path, and also for extension compatibility this means that things will break over time if unmaintained. Far from as radical as in Firefox, of course, but major milestone releases can and will see issues pop up that weren't present before.
We cannot hold back our core development progress for the sake of extensions, though. That would be a dead-end street.
The fact that we support Firefox extensions in our different browser is a bonus, one that we explicitly offered because of the importance of extensions for many users - even so, there is no guarantee that extensions made for a different browser work and will continue to work unaltered in Pale Moon.
Of course, we will do as much as we can to keep compatibility with Firefox extensions, but if extensions don't explicitly support us as a browser in their extension, things may simply not work 100%. To "fix" this, the extension developers need to provide explicit support for us. In many cases, this support is trivial and low-maintenance. Existing add-on developers don't have to do major re-writes, especially if they already supported Firefox in 2013.
People having problems with these add-ons have to understand that we can only do so much to be compatible with Firefox add-ons without being Firefox.
Unfortunately there's also only so much time left for Firefox add-ons before Mozilla will drop all of them from the browser in favor of WebExtensions. XUL and bootstrapped are already completely deprecated (called "legacy") by them, for starters, and may be dropped at any time. SDK add-ons are also deprecated and will also be dropped after an as of yet undetermined "transition" period.
For extension developers, this means they need to decide what they want to do; completely re-write their extension, continue to support a dead extension platform, or focus on a future where their work can thrive, by changing their product focus to us or at the least make their support explicit.
An additional issue is that extensions often check in any of many different ways what version of "Firefox" they are running on to try and be flexible for multiple versions of existing Firefox browsers. We've kept our extension API level as compatible as possible with Firefox 24, it being the closest to our fork-off point and it offering a solid base for extensions to work from. Since these extension checks are done almost always on product version, these extensions often make assumptions based on specific changes that occurred in Firefox with specific version numbers. For example, they may assume we are "Firefox 26" because Pale Moon is now at the v26 as a major version -- but we do not have a Firefox 26 API version for extensions. This breaks extensions with explicit checks in the extension and choosing a code path that relies on changed APIs in Firefox 26. Similarly, extensions that check on the arbitrary "platform version" break because they assume this is reflecting the Firefox platform version (which is equal to the product version). That's not the case any longer with Goanna, where we explicitly de-coupled platform version from product version again (Like Mozilla did previously, as well) to have it indeed be the platform (layout engine) version and not the product (browser) version.
First and foremost, people have to understand one thing above all else: Pale Moon is not Firefox!
I need to stress this because a lot of people still seem to think they are one and the same.
This is not a problem in Pale Moon. We have our own development path, and also for extension compatibility this means that things will break over time if unmaintained. Far from as radical as in Firefox, of course, but major milestone releases can and will see issues pop up that weren't present before.
We cannot hold back our core development progress for the sake of extensions, though. That would be a dead-end street.
The fact that we support Firefox extensions in our different browser is a bonus, one that we explicitly offered because of the importance of extensions for many users - even so, there is no guarantee that extensions made for a different browser work and will continue to work unaltered in Pale Moon.
Of course, we will do as much as we can to keep compatibility with Firefox extensions, but if extensions don't explicitly support us as a browser in their extension, things may simply not work 100%. To "fix" this, the extension developers need to provide explicit support for us. In many cases, this support is trivial and low-maintenance. Existing add-on developers don't have to do major re-writes, especially if they already supported Firefox in 2013.
People having problems with these add-ons have to understand that we can only do so much to be compatible with Firefox add-ons without being Firefox.
Unfortunately there's also only so much time left for Firefox add-ons before Mozilla will drop all of them from the browser in favor of WebExtensions. XUL and bootstrapped are already completely deprecated (called "legacy") by them, for starters, and may be dropped at any time. SDK add-ons are also deprecated and will also be dropped after an as of yet undetermined "transition" period.
For extension developers, this means they need to decide what they want to do; completely re-write their extension, continue to support a dead extension platform, or focus on a future where their work can thrive, by changing their product focus to us or at the least make their support explicit.
An additional issue is that extensions often check in any of many different ways what version of "Firefox" they are running on to try and be flexible for multiple versions of existing Firefox browsers. We've kept our extension API level as compatible as possible with Firefox 24, it being the closest to our fork-off point and it offering a solid base for extensions to work from. Since these extension checks are done almost always on product version, these extensions often make assumptions based on specific changes that occurred in Firefox with specific version numbers. For example, they may assume we are "Firefox 26" because Pale Moon is now at the v26 as a major version -- but we do not have a Firefox 26 API version for extensions. This breaks extensions with explicit checks in the extension and choosing a code path that relies on changed APIs in Firefox 26. Similarly, extensions that check on the arbitrary "platform version" break because they assume this is reflecting the Firefox platform version (which is equal to the product version). That's not the case any longer with Goanna, where we explicitly de-coupled platform version from product version again (Like Mozilla did previously, as well) to have it indeed be the platform (layout engine) version and not the product (browser) version.