Release 2.0.3.2 Bugfix

Remove prematurely (incomplete) option features.

These additional preferences should not have been released, these extra options do completely nothing.
They were added in preparation for a new feature but got accidentally released.
Apologies for that, it is fixed (removed) in this 2.0.3.2 release.

Release 2.0.3.1 German translation update

A small correction was needed for the German translation. The German datatables.json file which contains locale specific translations for the jQuery datatables plugin was not UTF-8 encoded.

Release 2.0.3.0 Language Update

Thanks to Michael Illgen who volunteered to do the German translation this add-on is now also available in German.

If you also want to participate here are the instructions:

• First download the add-on to a location of your choosing. You can download the latest version here: https://github.com/stephanmahieu/formhistorycontrol-2 and use the green "Clone or Download" button. Either use git (if you have that installed and know how to use it) or download the zipfile and unpack.
• The file you should translate is located in the \_locales\xx\ subdirectory where xx is the language tag of the country, the file should be named messages.json. If the xx directory does not exist yet, you can create it and copy the files from \_locales\en\ into the new xx directory. You can find more on this subject and links to find the correct country tag here: Reference/Global_Objects/Intl
• The messages.json file contains multiple labels with each having a message and a description. You should only translate the message part! The description is only there to give the translator an indication of what the message is used for (see for example the nl version). Please do not add empty lines or break up existing lines into multiple lines.
• The \locales\xx\ subdirectory also contains a datatables.json language file, this file is used by the jquery datatables plugin. For this plugin there are already many translations available.For a complete list see: https://datatables.net/plug-ins/i18n/.
• If you want to test your translation, you can do so in a separate Firefox profile. See support.mozilla.org on how to create an extra profile. Within this profile you can load the add-on version you downloaded in the first step by entering "about:debugging" in the URL bar and then click "Load Temporary Add-on". Next you choose the "manifest.json" file of the add-on you downloaded in the first step. The add-on should now be available in your profile (see mozilla for detailed instructions).
  If you are using an international version of Firefox, it may very well be that you are not seeing the desired translation but the (default) english translation instead. In that case you can switch the default language by entering "about:config" in the URL bar, search for "general.useragent.locale", and set the value to the tag for the desired language, for example "de" for German.
  In some cases switching the locale to does not work for whatever reason but it probably has something to do with not being able to display international characters. I can for example switch between dutch and english, but switching to greek (el) did not work for my FF version. If switching the language does not work, you  may have to download a Language specific version of Firefox.
  If you made changes in the messages.json file, you have to reload the add-on (on the about:debugging page) in order to see the changes
• When you are finished translating you can send the translated file back to me and I will add it to the release. If you are using git you can do a pull request, otherwise you may send the translated messages.json file to me by email.

Release 2.0.2.5, improved bugfix

The previous bugfix regarding not showing content proved to be not effective enough in all cases.
Opening windows from the dropdown-popup still behaved different from opening a window from a regular popup window, so opening a new window is now being handled by the background script.
Also in some cases (Linux/slow pc's) the html content in a newly created window was still showing blank, so I increased the no of attempts to 3 to refresh the window by varying the height one pixel.

Changes in this release:

• Bugfix 2 for not showing content in popup windows on some OS's and slow pc's (multiple attempts to restore content)
• Bugfix missing first letter of About window title

Bugfix release 2.0.2.4, fixing display issues

On some OS's, like Ubuntu with FF 57 content in popup windows were almost always hidden. Only after resizing did the content reveal itself.
This is probably caused by a weird bug in FF in relation to Linux ans possibly also MacOS.
The only fix I could come up with is displaying the popup window first and sending a width update next increasing the width 1 pixel.
Also the handling of sending and receiving messages behaved a little different, causing the close button for the preferences window not always showing up.
Hopefully this fixes all display issues.

Minor bugfix release 2.0.2.3

After a short break it is time to pickup the pace again. First some minor but annoying bugfixes.

Changed in this release:

• Display an error message when there is a problem with the database permission
• Hide URL column from small popup dialog to prevent messed up layout (URL remains searchable)

Formhistory not saved and/or empty database?

Data not stored?

If you experience problems regarding form history not being saved, please check if you have cookies enabled.
This add-on uses IndexedDB to store its information and according to this issue (see bugzilla) disabling cookies will prevent data being stored. So please check the Privacy and Security preferences of the browser and make sure that cookies are accepted or Form History Control will not be able to store your data.

Also note:
Some websites use advanced techniques and frameworks involving javascript that make it virtually impossible to capture user input in a generic way. On request I can add workarounds for popular websites/frameworks, please submit an issue and let me know for which website(s) capturing entries does not work (see Known Issues and github issues)

Empty database?

This add-on now uses the new mandatory WebExtensions API which no longer offers access to Firefox's built-in formhistory database. To overcome this limitation this add-on will create and maintain its own private formhistory database which initially will be empty.

There are two ways to get the formhistory data from the old version back into the new version:

1. If you have an export file from the old version, you can simply import that file into the new version. The exportfile is compatible with the new version.
2. If you have no importfile, you can use a standalone Java application that can export the formhistory data from the old version. You can find this program plus Instructions on my Githib page: https://github.com/stephanmahieu/formhistory-export

Still not working?

Despite rigorous testing on many websites and being a heavy user myself, it is very likely some issues have been overlooked or slipped through. So if you think this add-on is not saving the text you type on a particular website despite the fact you have cookies enabled let me know!
I will gladly investigate any problem you experience and try to figure out what the problem is so I can fix it and improve this add-on. By providing me with feedback you not only help yourself, it will also benefit other users who might run into the same problem.

Bugfixes 2.0.2.2

Some minor bugfixes:

• Tweak column widths in small datatable popup to prevent messed up layout
• Hold page position when updating and redrawing age in datatable
• Rename Wiky.js to wiky.js (fix wiki preview in entryview)
• Small increase (50px) entryview width

Bugfix 2.0.2.1

Bugfix: limit size of columns and preview in the small popup panel

Too much info for the columns so I had to decrease the width of the host and url columns.
Also opening details (with the plus icon) for values with a lot of data caused scrollbars to appear and messed up the layout. So I set a limit for the width and height.

Release 2.0.2.0 Some more small changes

Changes in this release:

• Add url to the tableview, searching now includes the url (someone needed this very bad)
• Added Markdown, Wiki and Text preview to entryview
• Remove inline styles when converting html to readable text
• Escape tooltip text in datatable view (fix values sometimes exceeding max length value column)

Release 2.0.1.0 Some small changes

Some small changes and bugfixes in this release.

• Add additional clickable icons to the small popup
• Copy text to clipboard now preserves HTML formatting
• Hide HTML tags from tableview, show readable text only
• Bugfix restore editor field contextmenu:
  
  • show international chars
  • sort hostname matches by date
  • exclude hostname matches from recent used
• Fix close button preference dialog not always visible

Release 2.0.0.3 Small usability changes

Setting the preference to ON for overriding the default autocomplete with a custom one was a bad mistake on my part. It does not make sense to turn on autocomplete that gets its values from a database that for the vast majority of users is still empty. Only in time, when more formhistory data is collected by the new add-on, does it make sense to switch to the custom autocomplete.

Thus in this version the default override-autocomplete preference is turned off.

B.t.w. The database is initially empty because the new API does not allow access to the builtin Firefox formhistory database. Therefor this add-on will start collecting its own set of formhistory entries.

Also the popup that appears when you left-click the icon (also initially empty because no data collected yet) will now show all entries instead of only the entries applicable to the current active webpage. I believe this is more intuitive.

Changes in this release:

• Show all data in the left-click popup dialog instead of just the fields for the active page (more intuitive)
• Set the override-automplete preference default to false

Release 2.0.0.2 bugfix

Adam reported the following issue via email:

Hello, in my opinion the latest version of the plugin History Form Control does not save textarea eg with gmail etc. The older she saved without problems.

Investigation of this issue revealed that GMail creates/updates an input form dynamically and thus no event handlers were attached to the form to capture user input.
Luckily I found a way to observe mutations made in the DOM tree which gave me a way to attach event-handlers to newly created elements.

After a bit of a struggle and some rigorous testing I came up with a decent solution. Hopefully this fixes all potential problems with dynamically added content.

Release 2.0.0.1 is out!

After a short review by Mozilla, the all new, WebExtension ready and Multiprocess compatible version of Form History Control has finally been released to the public.

Also thanks to the beta testers who tested the pre-releases published in the beta channel over the last couple of days. They gave me the confidence that this version was ready enough to go into production.

Coincidence or not, it took exacltly200 commits to get to this state. It was a tremendous amount of work and I still have plenty of work left on my todo list.

What is new or noteworthy in this almost completely redesigned version:

• The new API no longer offers access to the internal formhistory. This is both a bad and a good thing. The built-in formhistory only stores basic textinput fields and only when submitted in a standard way. I have taken a different approach which hopefully will catch more user-input.
  Each text-input field is stored the moment the field loses focus.Editor fields, which may contain multiple lines of text are captured while you type.
  Since both type of fields are now under my full control, I have chosen to store everything in the same table and also present them to the user in one table.
• The user interface is very different, the new API offers no widgets of any kind, so everything has to be designed from the ground up. For the table display I now use a jquery plugin to do all the hard work.
• Because this plugin now maintains a complete separate registration of captured text-fields, it made sense to also add a custom auto-complete system that is based on the formhistory maintained by this plugin. Since this new auto-complete system may not be to anyone's liking, it can be disabled through the preferences of this add-on.

The new add-on now uses the new mandatory API which no longer offers access to Firefox's built-in formhistory database. To get your old formhistory data into the new add-on you must first export the data using the previous versionof this add-on (1.4.0.6 or earlier) so you can import it into the new version.

Within the next few days I will provide a standalone app that can export the formhistory data from Firefox's database if you have already migrated to the new version.

New pre release (2.0.0pre2)

Just released a new pre release version, 2.0.0pre2

Changes in this pre release:

• Esc-key now closes (modal) dialogs
• Show extra info in header of small popup-window (showing history for current page)
• Redesign context-menus
• Styling preferences (alignment)
• Add Greek translation

First multiprocess/webextension Release

Finally, after many, many, many hours of work I decided that the current state of development was good enough to be released as version 2.0.0beta1 to the Bèta channel.

You can download the bèta release from here: https://addons.mozilla.org/firefox/addon/form-history-control/versions/beta

Be aware that this a a bèta version and may still contain some bugs.

If you are willing to test this version, any feedback is much appreciated.

If you want to transfer your current formhistory to the new version you can do so by first exporting the history from the old version and import them back in after you installed the new bèta version.

It might be wise to test this version first in a separate profile.

To give you an idea of the amount of work: the last 11 weeks I have done 166 commits to the source repository adding 16584 lines of code and deleting 9179 lines.

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.

Update 11 oct 2017:
I managed to get importing and exporting to work. You can even import files exported by the old extension!
This was high on my own priority list and I am very happy I got this working. It is also a very convenient way to get lots of data into the new extension for testing.

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.