1287892 - Provide access to webManifest data via AddonManager

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, defect, P5)

Description

[Bob Silverberg [:bsilverberg]]

In order to support bug 1282981, addons returned by AddonManager should expose certain data from the webManifest. Specifically, it should expose:

- short_name
- permissions

We discussed this in IRC and there was agreement to store shortName and permissions in the add-ons DB, and provide properties for them.

Comment 1

[Bob Silverberg [:bsilverberg]]

This will involve:
- storing the data in the AddonInternal object (https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/internal/XPIProvider.jsm#922)
- creating properties for shortName and permissions in the AddonWrapper (https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/internal/XPIProvider.jsm#7095)
- storing the new properties in the add-ons DB, by updating PROP_JSON_FIELDS (https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/internal/XPIProviderUtils.js#79)
- move the permissions parsing code in Extensions.jsm from the Extension object to ExtensionData, so that it can be accessed by XPIProvider

Comment 2

[Andrew Swan [:aswan]]

Sorry I missed the discussion on IRC, why do we think this should be in the add-ons DB?  Does getAll() return inactive extensions?  If not, it seems like you could do this right now without any changes (or at least with much smaller changes) using the GlobalManager in Extensions.jsm?

Comment 3

[Bob Silverberg [:bsilverberg]]

getAll does return disabled extensions, so if that makes it impossible to use GlobalManager then I guess that's a no-go. I am assuming we're going to use the AddonManager to get information about extensions for both get and getAll, as I did for getSelf. Does that seem like a reasonable approach?

Comment 4

[Bob Silverberg [:bsilverberg]]

Just following up on Andrew's comment, I took a look and I see how I can get manifest info from GlobalManager, so that would satisfy the requirement, but, if GlobalManager only includes active extensions (which I gather from comment #2 it does), then that won't work because getAll returns all extensions, both active and inactive. I will therefore continue down the path of making this data accessible from AddonManager unless I hear otherwise.

Comment 5

[Andrew Swan [:aswan]]

Adding this to the DB makes me wary, most of the add-ons manager and the xpi code in particular is generic and independent of the add-on type (i.e., whether or not it is a webextension).  There are exception to this of course but I think each one is a substantial maintenance burden.

What's the use case that getAll() supports?  The discussion over on bug 1282981 petered out before identifying any concrete applications.

Comment 6

[Bob Silverberg [:bsilverberg]]

This will be needed for both get() and getAll(). There were a few use cases presented in bug 1282981, but most of them were countered. I'm not sure about the arguments that question whether certain other extensions work in Firefox. Even if they do not, that does not preclude a developer from wanting to do something similar with an extension that does work with Firefox. 

I thought we had decided to implement getSelf, uninstallSelf, get and getAll to give us some parity with chrome's management API, but I suppose we do not have compelling use cases for the latter two. I can put any further work on this bug, and on get/getAll on hold until we have a chance to discuss it again together as a team. That likely won't be until I return in early August, but there is no huge urgency on this.

Comment 7

[Bob Silverberg [:bsilverberg]]

We've decided not to implement management.get or getAll at this time, and therefore this change is not needed. Bug 1282981 has been kept open, but with a P5 priority, and I'd like to save the research work done thus far on this bug, so rather than close it I'm just going to unassign it and downgrade it to a P5 as well.

Comment 8

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.