"aAddon must include an id, version, and type"

RESOLVED DUPLICATE of bug 1284407

Status

WebExtensions
Untriaged
RESOLVED DUPLICATE of bug 1284407
2 years ago
3 days ago

People

(Reporter: eerieso, Unassigned)

Tracking

48 Branch

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
The Mozilla documentation states that the manifest.json applications key is not mandatory as of Firefox 48 (https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/applications)

Yet I'm getting "aAddon must include an id, version, and type" from https://dxr.mozilla.org/mozilla-release/source/toolkit/mozapps/extensions/internal/XPIProvider.jsm#4706

Adding an id through the manifest.json applications key allows the addon to load.
(Reporter)

Comment 1

2 years ago
actually, it looks like this was because I put it (the webextension) into an xpi file. Is that not allowed? if not, is it a bug that it loaded after I added an id?
To clarify, this happens when you have a webextension without an id in the manifest packaged in an xpi and installed temporarily?
When I do the above in both 48 and nightly (51), I see the error from the subject appear in the browser console, but it doesn't prevent the extension from being installed.
Are you doing something different from what I described or getting a different outcome?
Flags: needinfo?(eerieso)
(Reporter)

Comment 3

2 years ago
"To clarify, this happens when you have a webextension without an id in the manifest packaged in an xpi and installed temporarily?"
Correct.

In Firefox 48, I get that error in the console even though the addon *appears* to load, however, I don't believe the addon has actually loaded because it's functionality doesn't work (functionality which works if I specify an id). If you look at the XPIProvider code I referenced, you should see why, as the conditional block which is triggering the console log message is also returning early from the callBootstrapMethod function.
Flags: needinfo?(eerieso)
Moving to Toolkit > WebExtensions, feel free to redispatch if I'm wrong.
Component: Developer Tools: about:debugging → WebExtensions
Product: Firefox → Toolkit
So two things:

1. I think this code should change to a throw, having it return silently without actually doing its thing is bad: https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/internal/XPIProvider.jsm#4813-4814  (Dave, any reason not to do that?)
2. Temporary install doesn't work on a webextension xpi that does not include an id in the manifest.  That's the real issue here but it was masked by #1.  Kumar, I have a vague recollection of a decision to not support temporary installation of packed xpis, am I mis-remembering that?  If it isn't meant to be supported then we need to improve the error message and if it is meant to be supported then of course it needs to be fixed.
Flags: needinfo?(kumar.mcmillan)
Flags: needinfo?(dtownsend)
(In reply to Andrew Swan [:aswan] from comment #5)
> Kumar, I have a vague recollection of a decision to not support
> temporary installation of packed xpis, am I mis-remembering that?

Temporary installation should support packed XPIs. If it's not working, sounds like a bug.

There were some bugs related to caching when *reloading* packed XPIs but I think they are fixed now. See bug 1283897 which landed in Firefox 50.
Flags: needinfo?(kumar.mcmillan)

Updated

2 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1284407
(In reply to Andrew Swan [:aswan] from comment #5)
> So two things:
> 
> 1. I think this code should change to a throw, having it return silently
> without actually doing its thing is bad:
> https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/
> internal/XPIProvider.jsm#4813-4814  (Dave, any reason not to do that?)

None I can think of.
Flags: needinfo?(dtownsend)

Updated

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