You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Skip to main content

Extension Uninstallation

From Front End to Removal

Uninstallation is accomplished by the user electing to remove an extension from the management UI and then restarting the application.

  1. User chooses to uninstall an extension from the management UI
  2. The chrome:toBeUninstalled property is set on the extension in the Extension Manager datasource.
  3. A .autoreg file is created in the profile directory alongside the profile Component Registry. The relative path to the extension's components is written to this file.

When the application is restarted and the Extension Manager is initialized, the following happens:

  1. XPCOM is initialized, the .autoreg file causes component re-registration (this is fine, people don't install/uninstall extensions so often), and the paths listed in the .autoreg file are specifically skipped.
  2. GetSources is used to identify any resources with the toBeUninstalled property set. (Potential optimization here - create a file in the profile directory whenever the datasource needs to be manipulated like this to avoid complex RDF operations on each startup)
  3. For extensions being uninstalled, the Extension Manager uses the chrome:file arcs to deregister chrome for the packages associated with the extension's files.
  4. An uninstall.log file is located at the root of the extension's hierarchy and is parsed, resulting in files being uninstalled.
  5. Once the uninstall log is parsed the file itself is removed and the directory containing it is removed.
  6. The application continues to start.

Disabling Extensions

Disabling is similar to uninstalling extensions in that the extension no longer takes effect, but the files are not removed, the extension remains in the Extension Manager datasource and the chrome packages remain registered.

After choosing to disable an extension through the front end, the following happens:

  1. The chrome:toBeDisabled property is set on the extension in the Extension Manager datasource.
  2. A .autoreg file is created in the profile directory alongside the profile Component Registry. The relative path to the extension's components is written to this file.

When the application is restarted and the Extension Manager is initialized, the following happens:

  1. XPCOM is initialized, the .autoreg file causes component re-registration (this is fine, people don't install/uninstall extensions so often), and the paths listed in the .autoreg file are specifically skipped.
  2. GetSources is used to identify any resources with the toBeDisabled property set. (Potential optimization here - create a file in the profile directory whenever the datasource needs to be manipulated like this to avoid complex RDF operations on each startup)
  3. For extensions being disabled, the Extension Manager uses the chrome:file arcs to call setAllowOverlaysForPackage on the chrome registry to disable dynamic overlays.
  4. Default prefs are not loaded.
  5. The application continues to start.

Problems?

When a new version of the application is installed and extensions are disabled during autoupdate, we need to restart the app to get the component deregistration aspect to "take"....