Tuesday, November 21, 2017 | 22:27

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: 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 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 Some small changes

Monday, November 20, 2017 | 00:43

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 Small usability changes

Wednesday, November 15, 2017 | 18:15

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 bugfix

Tuesday, November 14, 2017 | 21:48

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 is out!

Sunday, November 12, 2017 | 23:46

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 ( 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)

Saturday, November 11, 2017 | 18:06

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

Wednesday, November 8, 2017 | 21:52

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...

Sunday, May 21, 2017 | 15:10

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

Monday, March 20, 2017 | 12:59

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?

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 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.