From MozillaWiki
Jump to: navigation, search

Please note: we are in the process of removing the Hotfix, you should be using a system or go faster add-on instead.

The add-on hotfix is a tool used to ship changes to Firefox users that don't need to be distributed under the normal update mechanism. Examples of this are configuration changes that don't justify a point release, or changes that need to be pushed to users in older versions of Firefox.

Hotfix updates are automatically pushed to all Firefox users (starting from version 11).

How to develop a new hotfix

Please note: we are in the process of removing the Hotfix, you should be using a system or go faster add-on instead.

The code for the hotfixes is at

A new hotfix will live in a top-level dir following the convention vYYYYMMDD.XX. You can start by copying one of the existing ones into a new folder. The version must be greater than the version of the previously released one. Don't forget to update the README file (in the root srcdir) to include the bug number where the hotfix was developed and a description of what it does.

Package the hotfix by running HOTFIX=vYYYYMMDD.XX make package in the root srcdir. This instruction can also be found in the README file.


  • It's nicer to use hg copy to copy the folder so that the commit will display only the changes between the files.
  • Whenever we change a pref in a hotfix, we need to change the pref name in Firefox, otherwise users will get stuck with this custom value which won't be reset when Firefox updates

Testing the hotfix locally

To test the hotfix locally, get the .xpi file and drag&drop it into Firefox's window.

Things to look out for:

  • Test that the hotfix does what it is expected to do, obviously.
  • Test that the hotfix uninstalls itself after completing its task. Most of the hotfixes we've shipped so far performs an immediate task and uninstalls itself right afterwards, but there were some exceptions where it needs to remain installed until certain conditions are met.
  • Test the extension with the oldest Firefox version that it supports (minVersion), to make sure the code in the hotfix does not use any API or JS syntax that was introduced only on later versions.
  • Test on all target OSes.
  • Disable the strict compatibility checking and install the hotfix on an unsupported version to test that it does not perform its task, as expected. (The hotfix has code to check that it only runs on its target versions even with strictCompatiblity off).

Testing the hotfix on the staging server

To test the hotfix on the staging server, get it signed and uploaded to After that is done, do the following steps in a clean Firefox profile:

If testing on a Firefox version earlier than 24, make sure you have the right signature fingerprint configured. See the Signatures section for more details.

  • Check if is set to (it should be the default).
  • Set extensions.logging.enabled to true. This will log messages from the Add-ons Manager to the Console, and to stdout if in a debug build.
  • Set extensions.update.interval to 10.
  • In the pref extensions.update.background.url (extensions.update.url for Firefox < 13), change the part from the string with
  • Restart Firefox and open the Add-ons Manager and the Console. Wait a while for the Add-ons Manager to check for updates (messages about it should show in the Console).
    • Note that there might be other pending update checks that will run before, for example an update check for the "default theme" add-on, with id={972ce4c6-7e08-4474-a285-3208198ce6fd}.
    • If the hotfix is not being downloaded, get the URL from the logs and check that the RDF returned at that URL contains information about the hotfix. To make this easier, see the update check section.
    • After a successful update check is performed, the hotfix should be downloaded and installed.
  • Check that the hotfix performed its action correctly.
  • Check that the pref extensions.hotfix.lastVersion was set to the correct version name of the hotfix being tested.
  • Check that the hotfix was not downloaded and installed to incompatible Firefox versions.
  • Check that it uninstalled itself after completing its task. If you have the Add-ons Manager tab open, you might need to close and re-open it for the hotfix to disappear.


The hotfix extension is signed and the Add-ons Manager will only install it if it matches a pinned signature, stored in the extensions.hotfix.certs.1.sha1Fingerprint pref.

The signature has changed over time (in Firefox 16.0.2 and Firefox 24), and users with current installations were updated to the newer signatures through a hotfix itself (bug 803596 and bug 874513).

This means that a clean profile from Firefox 10 - 23 won't have the right signature from start, and it needs to be updated to proceed with the testing. The current correct value for the pref is 91:53:98:0C:C1:86:DF:47:8F:35:22:9E:11:C9:A7:31:04:49:A1:AA

Triggering the update check

To not wait on the update interval and manually trigger the update check, you can run the following code snippet. Please only do this when debugging things or when there's plenty of evidence that the timer update trigger is working properly.


Run this in a privileged script context, such as the Browser Console or Scratchpad set to the Browser environment.


Please note: we are in the process of removing the Hotfix, you should be using a system or go faster add-on instead.

  1. The intent to ship a new hotfix needs to be sent to release-drivers@m.o and moc@m.c by the developer, by a release manager, or by someone from the AMMO team (Example 1, Example 2 - Needs access to the r-d archives)
  2. Bug is filed (Example 1, Example 2)
  3. File a new bug in, and assign it to the Add-ons team for signing and staging. (:theone or :jorgev, otherwise contact the ACE team, ace-team@m.c) (Example 1, Example 2) with the following instructions (replace vYYYYMMDD.NN with the hotfix version):
    To generate the hotfix XPI, do the following:

    hg clone
    cd firefox-hotfixes
    HOTFIX=vYYYYMMDD.NN make package

    Then sign the xpi generated at build/hotfix-vYYYYMMDD.NN.xpi

    Please deploy to for QA
  4. File is signed and is attached to the signing bug.
  5. Signed file is uploaded to and published.
  6. Bug is reassigned to QA for testing.
  7. QA signs off, hotfix owner signs off, release management signs off.
  8. Bug is reassigned to Add-ons team for final deployment.
  9. Add-ons team notifies release-drivers@m.o and moc@m.c about the deployment, including bug number.
  10. Signed file is uploaded to and published.