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 1.4.0.6 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 addons.mozilla.org (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: https://support.mozilla.org/questions/998008

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\formhistory@yahoo.com, here you should find a META-INF subfolder with the following 3 files: manifest.mf, 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

Release 1.4.0.6

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

Release 1.4.0.5

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

Release 1.4.0.4

Thursday, May 14, 2015 | 11:18

Added Russian translation. (Translation kindly provided by Headly)

Release 1.4.0.3

Sunday, February 22, 2015 | 17:00

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

Release 1.4.0.2

Saturday, January 31, 2015 | 15:20

Fixed the performance issue by enabling the transaction mechanism.

The problem occurs when many formhistory entries are inserted into the database. By inserting entries inside a transaction, performance increases drastically. Inserting 300 entries now takes less than 150ms instead of the initial 64 seconds!

What a difference an additional true parameter can make :-)