Debug/Test extensions is harder than in Chrome, due to Add-On ID issues



2 years ago
7 months ago


(Reporter: jerry, Unassigned)


Firefox Tracking Flags

(Not tracked)




2 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/604.1.25 (KHTML, like Gecko) Version/11.0 Safari/604.1.25

Steps to reproduce:

1.  Build a extension for Firefox, Chrome and Opera (a WebExtension), particularly one using Native Messaging (permission: nativeMessaging).
2.  Debug it, or try and test it.

Actual results:

It's more painful than working with Google Chrome.

In this document,

it is stated that:

(1) "if your manifest.json does not contain an ID then the add-on will be assigned a randomly-generated temporary ID when you install it in Firefox through about:debugging"

It is also stated that:

"If you then restart Firefox and load the add-on again, it will get a new ID."

Expected results:

These behaviors are different than Google Chrome.

Regarding (1), Google Chrome does this too, but in their Extensions tab it **shows you** the randomly-generated ID.  I don't see any way to find the ID in Firefox.

Regarding (2), Google Chrome does not give you a new ID after restarting Chrome.  Maybe they hash the name or something.  Very nice.

Here's why these behaviors cause pain:

Because my extension uses Native Messaging, I must have the ID of the extension listed as one of the allowed_extensions in my Native Messaging Manifest, or it won't work.  Because Chrome shows me the ID, and because it is permanent, it's not too big of an issue.  In my Native Messaging Manifest, in allowed_extensions, I add the permanent randomly-generated ID after the store-generated IDs from Chrome, Opera and Firefox, and it "just works", either way.

But not for debugging or testing in Firefox.  With Firefox, I must add the "application" key to the extension's manifest, and then remember to remove it later because, as the same documentation states, "Google Chrome does not recognize the applications key and will show a warning if you include it."   Arghhhh.  And the need to add that key to the manifest means that I **cannot do a final test** of my extension after signing by Mozilla, by simply double-clicking the downloaded .xpi file.  It installs, but it doesn't work.

I suppose this issue could be addressed in several ways, but, to minimize cognitive overload among developers, I urge Mozilla to **just do it the way Chrome does** :)  That is,

(1) Expose the randomly-generated ID in the Add-Ons window.
(2) Make it permanent, and make it the same whether you install via "Load Temporary Add-On" or by double-clicking a signed or unsigned .xpi file.

P.S.  I do all of my work on a Mac.  Some details may be different on other platforms?

Thank you!
Component: Untriaged → WebExtensions: General
Product: Firefox → Toolkit

Comment 1

2 years ago
Please note that 1) is now shown in about:debugging in Firefox 55.


2 years ago
Flags: needinfo?(amckay)

Comment 2

2 years ago
(In reply to Andy McKay [:andym] from comment #1)
> Please note that 1) is now shown in about:debugging in Firefox 55.

Thank you, Andy.  Yes, I now see that, in Nightly (56).  The label "Internal UUID" is a bit of a head-scratcher, but it seems to have the correct string format, minus the obvious curly brackets, so I presume this is the desired extension ID.

However, I cannot test this for sure because of its non-permanent nature (issue "2").  The Native Messaging Manifest seems to be read when Firefox launches – it must be, because my tool launches when Firefox does.  So even if I copy the randomly-generated extension ID (aka "Internal UUID"), and paste it into my Native Messaging Manifest, save, then *Reload* the extension, it still doesn't work.  And if I relaunch Firefox, then it doesn't work either because now it's got a new randomly-generated ID.

So, as you suggested, indeed this bug is already half fixed.  Making those randomly-generated IDs permanent, by hashing the extensions name or whatever, would make things good :)

Comment 3

2 years ago
Not so fast there, I was wrong. There's two id's, an internal UUID and the add-on ID. I checked the nativeMessaging docs and realises it needs the add-on ID. That's not shown in about:debugging, but its pretty simple to add. I filed bug 1380818 for that.

As for the rest, I was chatting to Luca about this and he had the idea of creating the nativeMessaging parts automatically in web-ext. But I couldn't spot any bugs on that, Luca is there one?
Flags: needinfo?(amckay) → needinfo?(lgreco)
Priority: -- → P3

Comment 4

2 years ago
Thank you, Andy.  I don't quite understand your explanation of Luca's idea, but I'll just repeat that "doing it like Chrome does", even if it's a little suboptimal technically, has the advantage of being easier on the time budgets of us extension developers.  That's why I love WebExtensions :)

Comment 5

2 years ago
Including a explicit extension id in the extension manifest loaded from "about:debugging#addons" and ensuring that the same extension id is included in the "allowed_extensions" property (and not the "allowed_origins" used by Chrome) of the "native messaging host manifest" should be enough to make it work correctly.

Jerry, can you try the "allowed_extensions" property to confirm that it fixes the issue that you are experiencing?

Follows some additional details about "extension uuid vs. extension id" and the native messaging feature: 

Because of this "extension uuid (and origin as an consequence) vs. extension id" difference between Firefox and Chrome, there is a small difference in the app manifest format used by Firefox and the one used by Chrome:

- In Chrome, the allowed extensions are specified in the "native messaging host manifest" as "allowed_origins" (
- In Firefox, the allowed extension ids are specified in the "native messaging host manifest" as "allowed_extensions"

The reason is that on Firefox the extension urls are based on the extension uuid, which is auto-generated at install time ( for both temporarily installed addons and the ones signed and installed from AMO) and so the developer of the native app cannot use the "moz-extension://EXTENSION_UUID" url of the extension to restrict the native app to a known addon as chrome does, nevertheless we added an "allowed_extensions" property to that manifest to be able to specify the extension ids.

(My proposal to simplify the workflow of developing an extension paired with a nativa app and integrate it better with the "web-ext run" CLI command is mostly related to the "native messaging host manifest" discovery, which involves the registry on Windows, I'm going to file separate bugs for that, one on bugzilla for the changes needed in the Firefox sources and one on the web-ext CLI repository on github).
Flags: needinfo?(lgreco) → needinfo?(jerry)

Comment 6

2 years ago
Re-moving the needinfo, because after re-reading all the comments again I see that the "allowed_extensions" property has been already used.

I'll link to this bugzilla issue the github and bugzilla issue relative to the proposal for simplifying the development of extensions paired with a native app asap.
Flags: needinfo?(jerry)

Comment 7

a year ago
I've concluded that, at this time, it is not practical to package an extension for Firefox, Opera and Chrome and "just ship it" to all three.  So I bit the bullet and wrote a script which makes separate packages for Firefox, Opera, and Chrome.  Primarily, it adds the `applications` key to the manifest.json when building the Firefox package.

I published it here in case any other extension developers want to steal from it:


7 months ago
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.