Multiprocess Firefox is coming...

Firefox 55 will be released on August 8th.

One of the changes:
Recently, we turned on a restriction on Nightly that only allows multiprocess add-ons to be enabled. You can use a preference to toggle it.

See the full post about FF 55 add-on compatibility on the Mozilla Add-ons Blog.

Progress on the new version is slow. I have been very busy at work which is consuming much of my time and energy. I also have to spend more time in the garden and the vacation period is at hand. So please be patient, the new version is coming...

Form History Control II

I am happy to announce that work on porting this extension to e10s and web-extensions has started.

Not all functionality from the current version can be ported due to limitations imposed by the new API.
Due to he lack of a decent FileIO-API importing and exporting history will be impossible. The new API is also missing services to interact with the browsers internal Formhistory storage, so the new add-on must gather and maintain its own copy.

Form History Control end-of-life?

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 wiki.mozilla.org and blog.mozilla.org)

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

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

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

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

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