In the current developer version of Firefox (53.0a2), attempts to install a multi item xpi are failing with an error stating that the xpi file appears to be corrupted. The browser console identifies the problem as an unknown xpi type (i.e. the type 32 for multi-item xpi's has become now unknown).
In the latest code, starting at line 228 of https://github.com/mozilla/gecko-dev/blob/master/toolkit/mozapps/extensions/internal/XPIProvider.jsm
We read:
// Map new string type identifiers to old style nsIUpdateItem types
// Type 32 was previously used for multipackage xpi files so it should
// not be re-used since old files with that type may be floating around.
const TYPES = {
extension: 2,
theme: 4,
locale: 8,
dictionary: 64,
experiment: 128,
};
As the comment states, type 32, which was for multi-item xpi types, has been removed from the code.
However, I can find no documentation that the multipackage extension type is being deprecated separately or earlier than the add-on SDK itself, which previously supported it. Moreover, the web page:
Extension Packaging: https://developer.mozilla.org/en-US/Add-ons/Extension_Packaging was updated less than a month ago with the following update stamp: Last updated by: wbamberg, Jan 10, 2017, 3:51:23 PM
That page has a section "Multi-item extension XPIs"; notwithstanding the above removal from the latest code, this document section goes ahead and tells how to create multi-item xpi files. Note that developers who actually follow that direction, or attempt to migrate a legacy add-on would not be able to self-sign the add-on or turn off checking of signatures in current standard Firefox builds; thus they must use the developer version of Firefox, but the current developer version of Firefox does not support such an add-on.
What is/was the actual intent here with respect to the multi-item extension add-ons? For example, are they being deprecated separately and ahead of the rest of the add-on SDK? Can we use a new string identification rather than the integer, which is implied in the code comment above where it says "Map new string type identifiers to old style nsIUpdateItem types"?
