Form History Control end-of-life?

Saturday, February 4, 2017 | 16:55

As much as I like to further develop the FHC add-on, the upcoming changes by Mozilla make it very difficult, if not impossible, to keep this add-on compatible with future versions of Firefox.

The changes needed to make FHC multiprocess (aka Electrolysis or e10s) compatible are surely possible and probably not very hard to do (although it does probably take many, many hours of work to implement), but the changes needed to make it WebExtensions compatible and maintain it's current features are almost certainly impossible.

The API's supported by WebExtensions do not include an API for accessing the formhistory which is the base for one of the core features of this add-on.
Furthermore this add-on relies heavily on XUL for the GUI and that is also gone under WebExtensions, so the complete GUI and all its interactions have to be rewritten from scratch.

According to the timeline of mozilla, it looks like WebExtensions are becoming the standard for add-on development in Firefox and will be the only type of add-on supported in Firefox by the end of 2017. (see and

All things considered I have to conclude that this Form History Control add-on has come end-of-life.

Showing formhistory data gathered by the browser itself (for auto-completion) was originally the main purpose of this add-on and it seems like this data will no longer be available to add-ons, so hopefully at some point in time this will be built into the browser itself by Mozilla. Maybe, if I can find the time and inspiration, I will start building a new add-on that supports (re)storing formhistory data from textfields and editor-fields since this feature has often been very useful for me too.

When using Beta Firefox versions

Friday, November 25, 2016 | 15:39

When using a beta Firefox version , some add-ons might get disabled because its maxVersion is less then the beta Firefox version.

Another strange thing is that the maxVersion of the add-on as reported by the Mozilla add-on page might be different (newer) then the maxVersion that is actually set in the install.rdf of the add-on.

If you take a look at the FHC add-on page on mozilla right now it clearly states that version works with FF version 22.0 - 50.* but when you download the extension and take a look at the install.rdf file the maxVersion is actually set to 49.0. Yet, while using FF 50.0 on my computer at the moment, the formhistorycontrol add-on is not disabled.

This is what mozilla says about updates:

Compatibility Updates

During the automatic update checks, applications look for both new versions and updated compatibility information about the currently installed version of an add-on. This means that if your update manifest contains an entry for the currently installed version of the add-on, and the entry's targetApplication entry specifies a larger maxVersion then the application will use this value instead of that specified in the add-on's install.rdf. This can cause add-ons that are disabled for being incompatible to become enabled and add-ons that would normally not install to be installed.

So although the maxVersion is set to 49.0 at the moment, the automatic update check discovered the fact that the max version is actually set to 50.0 by mozilla (which you can verify easily by looking at the add-ons page using chrome for example).

This all leads to the fact that if you use a beta version beyond 50.* the add-on would be disabled since its compatibility has not been checked by Mozilla yet and the server-side compatibility bump has not been carried out yet to accommodate for that beta version.

So be careful when  using beta versions, add-ons might be automatically disabled because their maxVersion has not been bumped to the lastest Firefox beta version. And using a beta version, you should know how to deal with these issues.

Signing issues

Wednesday, August 10, 2016 | 08:05

I have been receiving some reports about this add-on not being signed or that the add-on is disabled after a Firefox update. In fact every add-on that can be downloaded and installed directly from Mozilla is digitally signed so that is definitely not what is causing this issue.

See also the Mozilla topic on extension signing, in the FAQ section:
  • How do I get my add-ons signed if they are hosted on (AMO)?
    No action is required. We automatically signed reviewed versions of all add-ons currently hosted on AMO. All new versions will be signed automatically after they pass review.

It turns out that many of the signing issues seem to be related to cleaning and/or protecting software like CCleaner and BleachBit. Other problems that might cause an add-on to be disabled are a corrupt add-on registry or some sort of caching issue which might also be caused by the aforementioned cleaning software. Some users reported that setting the Firefox option xpinstall.whitelist.required (about:config) to false and re-installing the add-on resolved their issue.

If you have issues with this add-on being automatically disabled and you are using cleaning software try playing around with the browser related cleaning options. If this does not help or you are not using any cleaning software you might find some solutions on this Mozilla support page:

You can easily see if this add-on is signed by examining the folder of the installed extension. First locate the profile folder, see here on how to do that. In the profile folder, navigate to extensions\, here you should find a META-INF subfolder with the following 3 files:, mozilla.rsa and mozilla.sf.
If the META-INF folder or any of its files inside are missing Firefox will regard the add-on as being unsigned. So either the add-on was downloaded from an untrusted source or some or all signing files were deleted (cleaned) at some point after being downloaded from the official Mozilla repository.

Technical info about the signing files: how-mozilla-signs-addons


Sunday, March 20, 2016 | 20:25

Some small improvements:
  • New copyToClipboard menubar submenu-item when displaying the "Editor History"-tab
  • Changed order in menu of copyToClipboard submenu-items to be more consistent
  • Fix: Use a more reliable way to determine the Gecko version (info tab preferences), patch kindly provided by Kevin


Saturday, March 12, 2016 | 19:07

Many things were broken in Firefox 45.0 due to some changes in the underlying javascript framework.
Having received a few error-reports I was triggered to fix this as soon as I had the time.

Changes in this release:
  • Many small bugfixes to make it compatible with Firefox 45.0
    • fix export settings
    • fix formfill from popup menu
    • fix adding new values or cleanup criteria manually
  • Bugfix to make it compatible with Firefox 47.0
    • fix UI (dialog window) dit not start
  • Added a menu-item to copy a value from the formhistory-list to the clipboard


Thursday, May 14, 2015 | 11:18

Added Russian translation. (Translation kindly provided by Headly)


Sunday, February 22, 2015 | 17:00

Another performance enhancement by saving additional formelements asynchronously, reducing the impact on form submissions to 1 millisecond.