Why do some extensions no longer work in v25?
Posted: 2014-10-11, 16:40
Note: this post has been superseded by viewtopic.php?f=24&t=8740 which provides a more updated version for the current situation.
Why do some extensions no longer work in Pale Moon 25.0?
Since there seems to be a big misunderstanding about why there is such a noticeable number of extensions that suddenly no longer worked in v25.0, and who is to blame for the breakage, here is an explanation, with the consequences attached to it:
Some Firefox extensions work and others don't. This is directly related to the GUID (the unique application identifier used by software).
Pale Moon 25.0 changed its GUID from the Firefox one to one of its own. That means that from an extension point of view, Pale Moon is a "brand new application" that the extension was not initially written for.
Normally, when an application's GUID is different than what an add-on expects, it will simply be rejected. However, to prevent the situation where, as a result, none of the Firefox extensions would work anymore, we added a dual-GUID system in v25. It can install native Pale Moon extensions (specifically targeting Pale Moon as an application with its shiny new GUID), and it can install Firefox extensions that target the Firefox GUID. In terms of Mozilla code, this is unprecedented: historically, Mozilla applications would only allow extensions to be installed that specifically target the application.
This new system only covers the installation routine for add-on installation. So, any add-on that has no other requirements to function but to pass the install check, will be allowed to install and run. This is why all Firefox extensions install but some don't function.
Many extensions still work out of the box in this "Firefox compatibility mode", specifically those that don't explicitly use the Firefox GUID in other parts of the extension besides the installation file.
We did not support things like targeted xul overlays (this would be the chrome.manifest thing you are seeing mentioned on the forum) as that has a lot of snags to it, and would defeat the purpose of changing the GUID anyway. Targeted overlays have to specifically indicate the GUID of the application the overlays are for. Many extensions don't use these types of overlays and use generic overlays instead (specifically, most extensions that are only written for one product use an overlay that applies to everything it is installed on). Conversely, extensions that want to target multiple applications in a single extension package generally do use targeted overlays to cater to the different user interfaces of different applications targeted. Those extensions are a problem for Pale Moon's new GUID system because there won't be any that match Pale Moon. As a result, buttons, menu entries, etc are missing, although the rest of the extension can still work.
As for Jetpack style extensions, this is a much more complex story, since Mozilla has been recommending people to make extensions with the SDK that pulls approved target apps from the SDK itself. Pale Moon is not part of that list; the GUID does not get compiled into the final Jetpack extension, and they will not function (at least, not without some editing and even then it may not suffice).
This is a way of locking developers into only approved Mozilla applications. If they built with our SDK, which includes the addition of the Pale Moon GUID, then they could target us in addition to the other Mozilla-based programs in the list. This is further complicated by Australis, and even more locking in that has happened in recent months. This is because the things we have in common are being deprecated and replaced with Australis-targeted technologies, especially for the user interface.
This does sound similar to Australis-only extensions, but you have to realize that an extension can use one of two types of technologies in a Mozilla-powered application: one being the traditional xul/toolkit-based technology and the other being Jetpack. In general, xul/toolkit based extensions are easy to convert or update, but Jetpack ones are not (if at all possible) because of the above reasons.
Now what does this mean as far as actual compatibility of the browser is concerned?
It means that in almost all cases, Pale Moon would be perfectly capable of running the extensions without any actual extension code changes. This is a big difference to what some people have compared this breakage to, that happened in Firefox: extensions that actually no longer worked because the browser user interface, the browser API or other essential code-related elements in the browser code were changed. With that kind of breakage (that has caused a lot of user- and developer-fatigue) making the extensions compatible again is not trivial.
The only reason it doesn't work on Pale Moon is because the extensions themselves are made restricted to only work on applications carrying an official Mozilla Firefox GUID (or whichever other application specifically targeted in the extension). It also means that the browser can't be "fixed" to accept overlays or code that is specifically targeting a different application (that would actually be breaking with the add-on specification) - and those are restrictions that are put in by the extension developer(s) themselves. It is up to the extension developers to make these changes, preferably making Pale Moon a proper install target as well while they are at it.
We can (and will) provide temporary workarounds in terms of pseudo-static extensions (meaning they are made to work but otherwise not maintained) until such time as the extension developer adds the necessary support.
As a side note: we have contacted add-on developers well ahead of time of the release of Pale Moon 25.0 to give them plenty of opportunity to make the necessary changes. Unfortunately, very few (even the biggest and most well-supported) extensions were updated before release.
Why do some extensions no longer work in Pale Moon 25.0?
Since there seems to be a big misunderstanding about why there is such a noticeable number of extensions that suddenly no longer worked in v25.0, and who is to blame for the breakage, here is an explanation, with the consequences attached to it:
Some Firefox extensions work and others don't. This is directly related to the GUID (the unique application identifier used by software).
Pale Moon 25.0 changed its GUID from the Firefox one to one of its own. That means that from an extension point of view, Pale Moon is a "brand new application" that the extension was not initially written for.
Normally, when an application's GUID is different than what an add-on expects, it will simply be rejected. However, to prevent the situation where, as a result, none of the Firefox extensions would work anymore, we added a dual-GUID system in v25. It can install native Pale Moon extensions (specifically targeting Pale Moon as an application with its shiny new GUID), and it can install Firefox extensions that target the Firefox GUID. In terms of Mozilla code, this is unprecedented: historically, Mozilla applications would only allow extensions to be installed that specifically target the application.
This new system only covers the installation routine for add-on installation. So, any add-on that has no other requirements to function but to pass the install check, will be allowed to install and run. This is why all Firefox extensions install but some don't function.
Many extensions still work out of the box in this "Firefox compatibility mode", specifically those that don't explicitly use the Firefox GUID in other parts of the extension besides the installation file.
We did not support things like targeted xul overlays (this would be the chrome.manifest thing you are seeing mentioned on the forum) as that has a lot of snags to it, and would defeat the purpose of changing the GUID anyway. Targeted overlays have to specifically indicate the GUID of the application the overlays are for. Many extensions don't use these types of overlays and use generic overlays instead (specifically, most extensions that are only written for one product use an overlay that applies to everything it is installed on). Conversely, extensions that want to target multiple applications in a single extension package generally do use targeted overlays to cater to the different user interfaces of different applications targeted. Those extensions are a problem for Pale Moon's new GUID system because there won't be any that match Pale Moon. As a result, buttons, menu entries, etc are missing, although the rest of the extension can still work.
As for Jetpack style extensions, this is a much more complex story, since Mozilla has been recommending people to make extensions with the SDK that pulls approved target apps from the SDK itself. Pale Moon is not part of that list; the GUID does not get compiled into the final Jetpack extension, and they will not function (at least, not without some editing and even then it may not suffice).
This is a way of locking developers into only approved Mozilla applications. If they built with our SDK, which includes the addition of the Pale Moon GUID, then they could target us in addition to the other Mozilla-based programs in the list. This is further complicated by Australis, and even more locking in that has happened in recent months. This is because the things we have in common are being deprecated and replaced with Australis-targeted technologies, especially for the user interface.
This does sound similar to Australis-only extensions, but you have to realize that an extension can use one of two types of technologies in a Mozilla-powered application: one being the traditional xul/toolkit-based technology and the other being Jetpack. In general, xul/toolkit based extensions are easy to convert or update, but Jetpack ones are not (if at all possible) because of the above reasons.
Now what does this mean as far as actual compatibility of the browser is concerned?
It means that in almost all cases, Pale Moon would be perfectly capable of running the extensions without any actual extension code changes. This is a big difference to what some people have compared this breakage to, that happened in Firefox: extensions that actually no longer worked because the browser user interface, the browser API or other essential code-related elements in the browser code were changed. With that kind of breakage (that has caused a lot of user- and developer-fatigue) making the extensions compatible again is not trivial.
The only reason it doesn't work on Pale Moon is because the extensions themselves are made restricted to only work on applications carrying an official Mozilla Firefox GUID (or whichever other application specifically targeted in the extension). It also means that the browser can't be "fixed" to accept overlays or code that is specifically targeting a different application (that would actually be breaking with the add-on specification) - and those are restrictions that are put in by the extension developer(s) themselves. It is up to the extension developers to make these changes, preferably making Pale Moon a proper install target as well while they are at it.
We can (and will) provide temporary workarounds in terms of pseudo-static extensions (meaning they are made to work but otherwise not maintained) until such time as the extension developer adds the necessary support.
As a side note: we have contacted add-on developers well ahead of time of the release of Pale Moon 25.0 to give them plenty of opportunity to make the necessary changes. Unfortunately, very few (even the biggest and most well-supported) extensions were updated before release.