913526 - Add-ons built with the addon sdk 1.14 (and 1.15) won't work in unofficial flavors of Firefox 23 (and 28)

Status: RESOLVED WORKSFORME

(Add-on SDK Graveyard :: General, defect)

Description

[Loic Duros]

Hi:

It seems the compatibility checks inside cuddlefish.js and xul_app.js have changed recently, and the following error in cuddlefish.js will be triggered in unofficial flavors of Firefox:
return new Error("Unsupported Application: The module " + id +
            " currently supports only " + applications.join(", ") + ".")


This is an issue, because a browser such as Abrowser 23, which is similar to Firefox 23 in all fashion will not be able to run addons built with the Addon SDK 1.14.

If you want to give this a try, I'd suggest to install a distribution with an unofficial version of Firefox, such as Trisquel, in a VM and see for yourself when trying to install an addon based on 1.14 inside its "Abrowser" application:
http://trisquel.info/en/download

Because there is no "Abrowser" key in the ids object, the function is(name) will not return it:
var ids = exports.ids = {
  Firefox: "{ec8030f7-c20a-464f-9b0e-13a3a9e97384}",
  Mozilla: "{86c18b42-e466-45a9-ae7a-9b95ba6f5640}",
  Sunbird: "{718e30fb-e89b-41dd-9da7-e25a45638b28}",
  SeaMonkey: "{92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}",
  Fennec: "{aa3c5121-dab2-40e2-81ca-7ea25febc110}",
  Thunderbird: "{3550f703-e582-4d05-9a08-453d09bdfdc6}"
};

function is(name) {
  if (!(name in ids))
    throw new Error("Unkown Mozilla Application: " + name);
  return ID == ids[name];
};

This issue doesn't happen with the addon sdk 1.13, because that code checking incompatibility is not there.

Thank you,

Comment 1

[Matteo Ferretti [:zer0] [:matteo]]

I would mark this as duplicate of bug 855651. If you're still experiencing this issue, or you're using an outdated version of SDK (like 1.14, instead the one shipped in Firefox), or the browser you're mentioning provides a different GUID – that means, it's a totally different application.

> Because there is no "Abrowser" key in the ids object, the function is(name)
> will not return it:

It actually doesn't matter the name of the browser, as soon as it's a rebranded Firefox, like – for instance – Iceweasel. Check this out, on the same `system/xul-app` module, you mentioned: 

"Using the GUID instead of the app's name is preferable because sometimes re-branded versions of a product have different names: for instance, Firefox, Minefield, Iceweasel, and Shiretoko all have the same GUID."
(see https://github.com/mozilla/addon-sdk/blob/master/lib/sdk/system/xul-app.js#L26-L31)

Basically if a module is marked as "Firefox" compatible, we check actually that the current GUID is the same of Firefox, we don't care what is the current app's name – this was fixed in the bug mentioned above.

Therefore, the fact that there is no "Abrowser" key in the ids object is irrelevant, as far the `appInfo.ID` (in the function `is`, it's the `ID` constant) is the same of Firefox.
If it's not, it means it is a totally different application; and the code base that we rely on to base the SDK could not exists.

Comment 2

[Dave Townsend [:mossop]]

Reopen if this is still an issue

Comment 3

[Loic Duros]

This issue still happens with the addon SDK 1.15 and occurs as well with other flavors of Firefox 28.
How to reproduce? I installed Trisquel (a free(er) flavor of Ubuntu) , which comes with Abrowser 28, which is Firefox 28 with a different name (and this small detail matters, as we'll see.)

If you are using Debian or Ubuntu, you should be able to install abrowser directly.
AMD64:
http://us.archive.trisquel.info/trisquel/pool/main/f/firefox/abrowser_28.0+build2-0ubuntu0.12.04.1+6.0trisquel12_amd64.deb
i386:
http://us.archive.trisquel.info/trisquel/pool/main/f/firefox/abrowser_28.0+build2-0ubuntu0.12.04.1+6.0trisquel12_i386.deb

using `sudo dpkg -i [name-of-package].deb' with the one corresponding to your architecture. Then close all your firefox windows, and type abrowser in the terminal.

When running "cfx xpi" using the addon sdk 1.15 to build the test addon and then attempting to install the generated XPI in Abrowser 28, you get the message that the addon cannot be installed and that the xpi file is corrupted. The xpi file does not have the sdk inside of it, so the issue is indeed in the SDK that ships with the Firefox codebase.

Here is how I fixed the problem temporarily. I went into the sdk 1.15 /system/xul-app.js
and had the "function isOneOf" definition always return true.

Then, when using the -o flag with 'cfx xpi', the local files will overload the ones that ship with Abrowser, and the addon will be working fine. The isOneOf is used by to check private browsing at installation time.

Thanks for your consideration,

Loic

Comment 4

[Tomislav Jovanovic :zombie]

i don't think the current approach scales well. we don't want to have to list all the possible forks, and we don't want to discourage forks, we are an open source project after all.

addon compatibility is/should be handled by the app GUID, so when a module claims to be compatible with "Firefox", we should in fact check that the app's GUID is equal to firefox's guid, and remove the check by name.

Comment 5

[Tomislav Jovanovic :zombie]

actually, it seems that's exactly what we do, see:

https://github.com/mozilla/addon-sdk/blob/master/lib/sdk/system/xul-app.js#L26

so i'm inclined to mark this as WONTFIX, and the proper solution to this problem is to get "Abrowser" to use the same GUID as Firefox, just like other non-official forks do.

Comment 6

[Matteo Ferretti [:zer0] [:matteo]]

(In reply to Loic Duros from comment #3)
> This issue still happens with the addon SDK 1.15 and occurs as well with
> other flavors of Firefox 28.
> How to reproduce? I installed Trisquel (a free(er) flavor of Ubuntu) , which
> comes with Abrowser 28, which is Firefox 28 with a different name (and this
> small detail matters, as we'll see.)

Unless we have some regression on this – but I don't think so – it means Abrowser 28 doesn't have just a different name, but also a different GUID. If it's the case, is not considered as a "fork" of Firefox, but as a totally different application – as it should be.
We can't guarantee that browsers that are originally forked by Firefox but they are different enough to don't have the same GUID are compatible with SDK.

So I suggest to you to check if the GUID of Abrowser is actually different from the GUID of Firefox, as suspected, and if it's the case you should probably ask to the Abrowser developers why they choose to have a different GUID – where other fork of Firefox keep the same, see Iceweasel.

(In reply to Tomislav Jovanovic [:zombie] from comment #4)

> addon compatibility is/should be handled by the app GUID, so when a module
> claims to be compatible with "Firefox", we should in fact check that the
> app's GUID is equal to firefox's guid, and remove the check by name.

That's exactly what we do, see my comment 1.

Comment 7

[Loic Duros]

Here is what I see in application.ini, of /usr/lib/abrowser/application.ini
(you can install a deb file and see for yourself)
Vendor=Mozilla
Name=Abrowser
Version=28.0
BuildID=20140319212537
ID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}

This to me looks like the same ID as what you see in xul-app.js:
var ids = exports.ids = {
  Firefox: "{ec8030f7-c20a-464f-9b0e-13a3a9e97384}",


I'll modify the sdk in there and see why there is a no match or an error thrown on that end. But something else is at work than just GUID, IMO.

Comment 8

[Loic Duros]

Hmm. After looking into the folder it looks like the sdk/ directory is entirely missing from that flavor :-\

That would explain why we are a corruption issue.

Comment 9

[Loic Duros]

Rectification: The SDK _is_ present inside the jar file.
jar:file:///usr/lib/abrowser/omni.ja!/modules/commonjs/sdk/

Hence, if the GUID used is the one present in application.ini, then there is with the code in xul-app.js or elsewhere.

I'll create an xpi to overload the sdk and console.log the GUID from xul-app. We'll get to the bottom of this.

Comment 10

[Loic Duros]

The addon appears to load fine in Ubuntu using Abrowser 28 and an addon without the SDK file overloaded. The issue may be in Abrowser running in Trisquel directly or with a given profile. I'll reopen if I can reproduce.