Overview

Extensions should be able to depend on other extensions. For 1.8, this can simply be the EM refusing to enable an extension until another extension is installed+enabled. In 1.9 timeframe it would be good to ask UMO to help resolve extension dependencies for semi-automatic download and install.

For bonus points, when an extension specifies a dependency it should be able to provide a download link + extension title, not just the extension ID.

Work is happening in bug 298497

Notes

• For brevity this document uses the term item for all items that will support em:requires (e.g. extensions and themes).
• The term dependency refers to an item that another item requires to function properly. The information for a dependency is specified in an item's install manifest em:requires section.
• A dependency is satisfied when an additional item is installed with the same id and a version number that is compatible when version checked (e.g. nsIVersionChecker) based on the minVersion and maxVersion as specified in the em:requires section of an item's install manifest and that item is enabled.
• When an item is installed, upgraded, or uninstalled using a method other than a manager (e.g. Extension / Theme Manager) items that do not have their dependencies satisfied will be disabled and their description field will state why the item is disabled.
• When an item is disabled by not having its dependencies satisfied the item will be disabled by a new property (e.g. appDisabled) rather than the disabled property. This will make it possible to automatically enable an item that in the future has its dependencies satisfied without enabling it when it was manually disabled. See bug 264750 for an example and this new property could also be used in that scenario. A patch for bug 264750 has been checked in.

Proposed em:requires Install Manifest Format (future)

Currently only the em:id, em:minVersion, and em:maxVersion are supported.

  <em:requires>
    <Description>
      <em:id>extension@somewhere.org</em:id>
      <em:name>Some Other Extension</em:name>
      <em:homepageURL>http://somewhere.org/</em:homepageURL>
      <em:updateURL>http://somewhere.org/someotherExt.rdf</em:updateURL>
      <em:minVersion>0.3.1</em:minVersion>
      <em:maxVersion>0.8.9</em:maxVersion>
    </Description>
  </em:requires>

updateURL will default to UMO when it is not specified the same as it does when checking for updates to an item that do not specify an updateURL.

Q: We could just not have updateURL and require the dependency to be hosted on UMO to provide an option to install the dependency during installation of an item with an em:requires
A: If that's simpler for 1.1, do it. In the long term we do want to have the optional custom updateURL

Item Install & Upgrade (partially completed)

When installing or upgrading using a manager (e.g. Extension / Theme Manager) after all installations in progress complete if a dependency is not satisfied the item would have the appDisabled property set to true and the user would be notified via a dialog that an item requires additional items to be installed or enabled.
Note The current implementation does not display a dialog on install. It does set the appDisabled property to true when the install completes if the item does not have its dependencies satisfied.

When an item that is a dependency of another item is being upgraded and the upgrade will disable the item that depends on it the user would be notified and given the option to not upgrade the item.
Note The current implementation does not notify the user on upgrade.

Future: If the required item is not installed:

• if em:requires provides a homepageURL the user would be provided with a link to the required item's home page.
• the user will always be given the option of installing the required items since updateURL will default to UMO when it is not specified.

Q: I believe that UMO has only recently started to return the rdf data when the item installed was the same version as the latest item available. It appears that it is now returning the data in this case and implementing this would require UMO to always return the data.

Item Uninstall and Disable (completed)

When uninstalling or disabling an item the user will be warned if doing so will disable another item that requires it. Instead of displaying a prompt informing the user "If you uninstall..." the text should also include "The following items that require this item will be disabled..."

If an item that is a dependency is uninstalled without using a manager (e.g. Extension / Theme Manager) then the dependent item would be disabled as part of the normal application startup process due to it not having its dependencies satisfied.

Item Updates (future)

When an item that is a dependency of another item is being upgraded through the update mechanism if the upgrade will disable the item that depends on it the user should be notified and given the option to not upgrade the item.

Future: Just as the minVersion and maxVersion for application compatibility is automatically updated via the rdf specified in the item's updateURL the minVersion and maxVersion for an em:requires should also be updated automatically. Since this is version specific information adding and removing em:requires would not be supported since that should only occur during a version upgrade and not a compatibility update.

User Interface (partially completed)

Items that are disabled due to dependencies not being satisfied would have the same available commands as an incompatible item. In addition to these commands they would also have the option to bring up the dialog used during install for installing the extensions specified in em:requires that are currently not installed or enabled on their system.
Note The item has the proper commands available and status message in the user interface but the dialog is not yet implemented.

Application Startup (completed)

When operations are needed (e.g. needs-install, needs-upgrade, etc.) after the operations are completed all enabled items with dependencies will have their dependencies verified and the item's appDisabled property will be set accordingly.

Questions

Q: Should there be new user interface for disabling extension updates on individual extensions?
A: Possibly, but this is a low priority.

Q: When an extension is updated what should be done with extensions that are no longer required? For example, if after upgrading an extension it no longer requires jslib and it was the only extension requiring it should there be an indication of this to the user and if so what?
A: At this point we should not uninstall anything unless the user specifically requests it.
Q: What about providing an indication to the user? At this stage I don't think it is practical to include this but it is something to consider for the future.