Currently, the Add-ons Manager uses nsIRDFService to read install.rdf - we'd like to kill that with fire. However, we can't just drop support for install.rdf. Instead, I'd like to move to using the RDF reader JSM that bug 857454 will implement.

:mak, it seems like we can close this now that we only support web extensions. Is that correct?

We still support legacy extensions (which use install.rdf) for things like system addons and extensions used in automation. Switching these over to json so we can ditch rdf would be a fine thing but there are a lot of pieces to update.

(In reply to Andrew Swan [:aswan] from comment #2) > We still support legacy extensions (which use install.rdf) for things like > system addons and extensions used in automation. Switching these over to > json so we can ditch rdf would be a fine thing but there are a lot of pieces > to update. Do we have a list somewhere? How long do we plan on supporting them?

(In reply to Eric Rahm [:erahm] (please no mozreview requests) from comment #3) > (In reply to Andrew Swan [:aswan] from comment #2) > > We still support legacy extensions (which use install.rdf) for things like > > system addons and extensions used in automation. Switching these over to > > json so we can ditch rdf would be a fine thing but there are a lot of pieces > > to update. > > Do we have a list somewhere? How long do we plan on supporting them? I don't mean this to be cheeky but I would start with something like: http://searchfox.org/mozilla-central/search?q=&case=false&regexp=false&path=install.rdf Off the top of my head, test pilot and devtools are the other big users of legacy extensions. This has sort of been in the background for a while but folks working on addons have had a lot of other things in front of us. Now that 57 is mostly done we can come back to things like this. Just out of curiosity, is there something other than a general desire to get rid of old cruft that brought this to the foreground right now?

(In reply to Andrew Swan [:aswan] from comment #4) > (In reply to Eric Rahm [:erahm] (please no mozreview requests) from comment > #3) > > (In reply to Andrew Swan [:aswan] from comment #2) > > > We still support legacy extensions (which use install.rdf) for things like > > > system addons and extensions used in automation. Switching these over to > > > json so we can ditch rdf would be a fine thing but there are a lot of pieces > > > to update. > > > > Do we have a list somewhere? How long do we plan on supporting them? > > I don't mean this to be cheeky but I would start with something like: > http://searchfox.org/mozilla-central/ > search?q=&case=false&regexp=false&path=install.rdf That's reasonable! Looks like we have quite a few (even ignoring tests). > This has sort of been in the background for a while but folks working on > addons have had a lot of other things in front of us. Now that 57 is mostly > done we can come back to things like this. Just out of curiosity, is there > something other than a general desire to get rid of old cruft that brought > this to the foreground right now? I'm trying to revive the removal of RDF (which I get is probably low priority). It seems like adding a shim for parsing add-on install manifests might be the easiest route or I guess adding json support and some sort of automated conversion.

(In reply to Eric Rahm [:erahm] (please no mozreview requests) from comment #5) > I'm trying to revive the removal of RDF (which I get is probably low > priority). It seems like adding a shim for parsing add-on install manifests > might be the easiest route or I guess adding json support and some sort of > automated conversion. I'd vote for just getting rid of it completely. The very crude outline is of course: 1. Offer a json alternative 2. Convert existing users over 3. Rip out the rdf support I don't think #1 will be too tough, let me see if I can crank something out to get the ball rolling.

As per bug 357276

While we won't get a reader, install.rdf is far from being gone: https://searchfox.org/mozilla-central/search?q=install.rdf&path= It's true now we don't support legacy add-ons by default, but still the situation doesn't allow to remove rdf code.

Update: we have removed a bunch of addon types that used install.rdf. The two remaining are dictionaries and bootstrapped extensions. Rather than changing from install.rdf to a JSON format as suggested in comment 6, we will remove support for both of these extension types (in favor of WebExtension-based alternatives). The dependencies on this bug cover that effort.

AddonInternal objects have a "type" field which is used inside the addon manager, but AddonWrapper objects map the internal values to different externally visible values. The internal values generally convey whether a particular addon uses webextension packaging (ie manifest.json) or not. This patch cleans that all up by adding a new isWebExtension property and then just using the externally visible values for type consistently.

This patch adds a hook to the addon manager that can be used to teach it how to load xpi-packaged addons that the addon manager doesn't already know about. Handing for install.rdf/bootstrap.js is (temporarily) converted to use this hook rather than being built directly into the addon manager.

The addon manager has a bunch of handling for "strict compatibility" -- an option for individual profiles and addons to control exactly how compatibility is handled. However, WebExtensions don't use or expose this feature. We want to retain this capability for other projects that use the addon manager but since it cannot be tested with WebExtensions, this patch converts its tests to use the new extension loading hook added in the previous patch.

First draft patches are up on phabricator. For folks working on Thunderbird or Sea Monkey or anything else that uses toolkit and wants to keep using bootstrapped extensions, you'll basically want to revert the part 4 patch and reinstate BootstrapHandler.jsm in some appropriate place. I think we would accept patches to change the way the handler is loaded (eg to use the category manager) but I didn't want to try to handle that without understanding how other projects will actually use this.

Andrew, thanks a lot for the details. I hope out "add-ons man" Geoff can handle it.

Thanks Andrew, this all looks reasonable and I think I understand what I'll need to do. I'm guessing your ETA is at the end of this week?

That's the rough plan, yes.

I've copied everything across and mostly working as expected, but the tests stop at a call to AddonManager.getInstallForFile, which returns an AddonInstall with most properties set to null. This isn't intended, is it?

No. I'd be happy to help if you can give a little more detail, but lets keep that discussion over on bug 1510097.

https://hg.mozilla.org/integration/mozilla-inbound/rev/efac27a2bec4fa7e81fa3c8a6d023795aa6447dc Bug 857456 Part 0: Clean up remaining tests using legacy extensions r=kmag https://hg.mozilla.org/integration/mozilla-inbound/rev/51bb2e2f30d2c1486ebbc75568e09976a374fe6c Bug 857456 Part 1: Get rid of internal/external type distinction in addons manager r=kmag https://hg.mozilla.org/integration/mozilla-inbound/rev/061b97e02ede2133f50956feba25fd8798745347 Bug 857456 Part 2: Separate handling for non-webextensions from the addons manager r=kmag https://hg.mozilla.org/integration/mozilla-inbound/rev/e3b6db3b34ab06b60ab5b0f9d8d5695df754b7e1 Bug 857456 Part 3: Convert (non-) strict compatibility tests to use an external extension loader r=kmag https://hg.mozilla.org/integration/mozilla-inbound/rev/0c715a8f0170fd4b19c4281c269c03f872090648 Bug 857456 Part 4: Remove toolkit support for install.rdf r=kmag

https://hg.mozilla.org/integration/mozilla-inbound/rev/368e88f08417bc4edcd4c4b48b43369083f0e7b4 Bug 857456 Follow-up: temporarily disable addon test in testDistribution.java rs=nalexander

https://hg.mozilla.org/mozilla-central/rev/efac27a2bec4 https://hg.mozilla.org/mozilla-central/rev/51bb2e2f30d2 https://hg.mozilla.org/mozilla-central/rev/061b97e02ede https://hg.mozilla.org/mozilla-central/rev/e3b6db3b34ab https://hg.mozilla.org/mozilla-central/rev/0c715a8f0170 https://hg.mozilla.org/mozilla-central/rev/368e88f08417