Feature requests

Wednesday, May 27, 2009 | 11:00

Add your own requests or ideas by commenting this post...

Configurable remember history
  • Stephan, Nov. 16, 2010: enable/disable formfill based on a (part of a) URL or domain.
    As an option a user should be able to maintain a list of sites and/or domains to indicate when formfill should be enabled or disabled.

Keybindings
  • Steve, Oct 21, 2010: Doesn't look like there are Keybindings? I'm using Seamonkey and am versed in hacking keybindings via platformHTMLBindings.xml.
  • Stephan, Nov 2010: Added keyboard-shortcut preferences in release 1.2.8 (no hacking required)

Disable context menu
  • niko23, Aug 13, 2010: One important thing is missing: Option to disable right click context menus that this add-on creates. My context menu is already cluttered and I use main window when I want to find or change something. Just an option to disable context menu if someone want to would be a nice thing.
  • Stephan, Oct 2010: Incorporated in release 1.2.7

Add advanced search filter
  • Anonymous, Oct 2, 2009: Filter based on date and time last visited, number of visits. It's already listed on the advanced cleanup option but move some of the function to the search box of the main tab.
  • Stephan, April, 2010: Added a advanced search option to version 1.2.1

Associate URL with data
  • Anonymous, Sept 27, 2009: Any possibility of displaying the URL that the data is associated with when it is saved? And perhaps you could search those listed pages for the field name/id.
  • Stephan, October, 2010: Added URL feature to version 1.2.7. However: Associated URL's may trigger actions upon revisit, so the page will never be searched for the presence of fields.

Add a "not cleanup criteria"
  • Ty, Sept 27, 2009: Can you add a "not cleanup criteria"
  • Stephan, April, 2010: Added feature to version 1.2.1

Right click context menu for searchbar
  • Anonymous, Sept 22, 2009: The search bar field doesn't have the form control in the right click context menu. Please add it as it's easier to manage entries using form control UI then the native Firefox UI.
  • Stephan, April, 2010: Added feature to version 1.2.1

Export history as CSV
  • Anonymous, Sept 17, 2009: The XML export could easily be exported as CSV which is easier to manipulate in spreadsheets
  • Stephan, April, 2010: Added feature to version 1.2.1

Put the option for case senstivity on the dialog box itself
  • Anonymous, Sept 17, 2009: It's standard procedure in most applications (and is on firefox as well - see CTRL-F in page find for an example where it states "match case")
  • Stephan, April, 2010: Added feature to version 1.2.1

Make the Form History Control dialog box non-exclusive
  • Anonymous, Sept 16, 2009: Currently you can't edit the webpage on the window you called Form control from.
  • Stephan, April, 2010: Added feature to version 1.2.1

Make each line entry editable inplace on the listbox
  • Anonymous, Sept 16, 2009: I've seen other applications with this feature but can't recall where.
  • Stephan, April, 2010: Added feature to version 1.2.1

Sort order:
  • Mega, July 08, 2009: Possibility to change the order of the values of a field

Toolbar button:
  • TheAssassin, June 23, 2009: A toolbar button, to clean the entries according to predefined rules, would be useful
  • Stephan, April, 2010: Added feature to version 1.2.1

Improve key navigation:
  • DonGato, June 6, 2009: Set the cursor to the next available entry after you delete an entry (or multiple ones) as now there is no selection after that so it's hard to navigate by keys.
  • Stephan, June 6, 2009: Added feature to version 1.0.4

109 comments:

Mega said...

Possibility to change the order of the values of a field.

Stephan Mahieu said...

I am not sure if that is possible. Right now it seems that Firefox sorts the history in alphabetical order (determined by the index of the database). It would be nice indeed if you could for instance sort by popularity or by last-used-date.

I am going to look into this, for this would be a nice feature.

Stephan Mahieu said...

Changing the sort order is possible by altering the index of the formhistory database. I am very reluctant however to mess with a database that comes shipped with Firefox as it can cause some unwanted side effects or interfere with future updates.
Perhaps there is another way to override Firefox's behavior...

Anonymous said...

SYNCING FIELDNAMES

Have it possible to sync entries between many different field names. For example between q, query and searchbar-history which are the form elements for search history on google, other websites and for the search bar history. This would enable better UI.

Make the Form History Control dialog box non-exclusive - currently you can't edit the webpage on the window you called Form control from.

Make each line entry editable inplace on the listbox. I've seen other applications with this feature but can't recall where.

Also does anyone know of addons that would allow autocompleting based on the string typed being a substring of the field's history? So typing in Tokyo would bring up "Tokyo" like normal but also "I live in Tokyo".

Anonymous said...

Also if the cursor is not in or over a field in a form hide the "Form History" entry - it just clutters it up without much benefit.

Also I've looked at the XML export and it could be easily be exported as CSV which is easier to manipulate in spreadsheets. Why have you put the dates in a subtree (excuse the terminology - i'm not totally up to speed with XML, hence the request).

Anonymous said...

One last thing - please put the option for case senstivity on the dialog box itself. It's standard procedure in most applications (and is on firefox as well - see CTRL-F in page find for an example where it states "match case")

Stephan Mahieu said...

Many good suggestions have been added over the last couple of days. I like the suggested improvements very much and I will try to incorporate them all in the next release.

Anonymous said...

Same person here.

The search bar field doesn't have the form control in the right click context menu. Please add it as it's easier to manage entries using form control UI then the native Firefox UI.

Anonymous said...

Any possibility of displaying the URL that the data is associated with when it is saved?

Anonymous said...

Do you can add a "not cleanup criteria"?
Ty.

Stephan Mahieu said...

It is not possible to display the associated URL because it is not stored by Firefox. Login information however (username, password) is stored with an associated URL but not in the form history database.

About the "not cleanup criteria": That would become something like "cleanup all except...". I could add an option so you can invert the behavior. I will look into this.

Anonymous said...

Nothing is impossible - just very hard. Last visit date and time (and maybe first date and time) is stored for both form history and browser history. It would be possible to search based on this and get a few pages one of which would have the domain. Perhaps if you want brownie points you could search those listed pages for the field name/id.

Also though not a high priority for me add in more options besides case sensitivity - filter based on date and time last visited, number of visits. It's already listed on the advanced cleanup option but move some of the function to the search box of the main tab. I understand if you don't want to ease of use and cluttering of the interface.

Stephan Mahieu said...

Linking Form history to URL's as described above might work, but many formfields have identical names across different sites/pages, so displaying a domain would only show the last one (fieldnames like 'q' or 'name' for example). Furthermore I am a bit worried about the impact on the performance. Maybe in the future this will be built-in to Firefox.

I like the idea of an advanced search/filter option. That would be relatively easy to implement.

Anonymous said...

a fork or alternate setting where the default is to remove an item and only those whitelisted/protected are kept

Many thanks:
Shiny

Anonymous said...

Is it possible to remember a history of dropdown
menu selections in a Form, kind of like how Safari does it?

Stephan Mahieu said...

If you want to remove everything except those whitelisted/protected then activating cleanup option "Remove all Form History Entries used less than 0 times" with a value of zero will achieve that.

Anonymous said...

Please add a mechanism to autofill form fields that have autocomplete="off" set?!

Stephan Mahieu said...

The problem with fields that have autocomplete="off" is that their history is not stored by the browser. If there is no history then there is also no data available for the autofill to put in the formfield.

Anonymous said...

Actually, for me, it's type="password" not autocomplete="off" that doesn't get autofilled. Just fyi I suppose because suspect your answer still applies.

Stephan Mahieu said...

Yes my answer still applies. I find it annoying too, but there is a little trick you can use. By using a bookmarklet you can temporarily change the behavior of the page and have the password field stored. Google for bookmarklet password save and you will find what you need.

Anonymous said...

thanks! in case anyone else is listening, the details are available in the "Sites prohibit password saving"
section of http://kb.mozillazine.org/User_name_and_password_not_remembered

Anonymous said...

Hi there,
Maybe I'm asking to much, but I'd love to have control on *any* input field, including:
- radio buttons;
- text boxes;
- drop down lists;
- ...
I'm currently trying version 1.2.8pre2 on SeaMonkey 2.0.10.
Cheers,
^m'e

Stephan Mahieu said...

I have no plans (yet) to incorporate other controls like radio buttons and checkboxes, just the textfields already stored by the browser. I am planning however to add support for multiline textfields in the near future.
After doing a quick search I just realized that there are actually not that many form-fill extensions for SM out there (in fact I can find only one(!) which is Windows only). I will give it some more thought, but no promises...

Philicia Bowen said...

Hello,

It would be really wonderful if one had the capability to change to default locations of the Forms History and CleanUp databases. I have a specific folder in my Documents just for Back-Up files for things like Registry key, data files and...well...things like this.

At least I assume that these fields are not modifiable since when I attempted to paste my path in place of what is there, or highlight and delete the path, it wouldn't work. Hence my suggestion... :-D

Lemmee know if you like,
pbowen

Stephan Mahieu said...

Hi Philicia,

You can move your entire profile directory including all databases. See this article for more information.

Anonymous said...

Just to let you know, American Express cards are different to most credit cards. They have the form ^\d{4}-?\d{6}-?\d{5}$ . It'd be nice to have a preset search for this. I'm not sure if Diner's etc. are similar?

Cheers.

Stephan Mahieu said...

Very informative website about regex for credit cards: regular-expressions.info
American Express starts with 34 or 37 and have 15 digits.
I will look into this...

Unknown said...

Q: My problem was that FF 'remembered' my credit card # & security code & was autofilling them on a website I bought some Xmas presents on. (I disabled this FOR THAT SITE-- Thank you!!!). Now I want to know if I can prevent FF from EVER 'remembering' cc info. How to do this w. Form History Control? How to find out?

Stephan Mahieu said...

Hi Thea,

At this moment you can not prevent the storage of individual fields, but I am working on a new feature that will disable saving form history for particular sites. I will try to extend that with the possibility to prevent the saving of data that meets certain criteria like credit card numbers.

Also you can already use the automatic cleanup option. Add a cleanup criteria to the list and turn on the Automatic cleanup. This will erase all data matching your cleanup criteria when you close the browser tab or shut down the browser. As cleanup criteria you can use a regular expression. There is also a preview option so you can test beforehand what the cleanup would delete. Send me a PM if you need help with this.

Ale said...

Is it possible to add a cleanup criteria for the field "Times used" ?

Stephan Mahieu said...

You already can: Use the option "Remove all Form History entries used less than X times" where X is the amount of days.

Ale said...

I already use this option, I set the the amount of the days 9999, but sometimes I would clear "Times used" because I use some entries very often and I don't want to reach 9999. How can I do ?

Ale said...

Sorry, I don't speak English well. If possible, I need to reset the value "Times used".
Thank you.

Stephan Mahieu said...

I see. What I can do for example is make this field editable (in the editwindow of the entry). And then, when you select multiple entries and choose edit, you can change all "Times used" fields to a specific value at once.
Would that help?

Ale said...

It would be perfect for me !

nxh said...

The ability to set background, foreground and related colors for the search and regex screens.

These two places (regex in options, and the main search) use modified colors. Since here global settings are ignored, the addon should provide an interface to customize these colors.

That should apply to all addons in general.

Stephan Mahieu said...

These abilities will be present in the next release. (see beta version)

Huw said...

Tiny tweaks:

1. Remove sub-menu from Firefox Tools menu by making Options only accessible from the control itself. That would mean time & effort saved overall - it's very rare you want to go straight to Options, & very common you want to open the control panel.

2. In the Firefox add-ons page you say "If you ever had to clear your entire form history because you keyed in a password in the wrong form field, or you just want to easily correct misspelled entries, this is the extension for you." BUT there is actually a way to delete a single entry direct from standard Firefox. Double-click in the form field with the entry you want to delete, then highlight the entry using cursor keys. Shift+Delete removes the entry. You might lose the occasional download by revealing that useful tip, but I think the goodwill generated would be worth it.

3. Have a check-box column in the Show History view for manually selecting entries to delete. Ctrl+click selecting is prone to losing your whole selection with one miss-click, & "Add as cleanup criteria" is a bit of a slow way to do what I want to do: manually view history, sorting by different fields & gradually building up a selection to delete. I like to keep "Warn before deleting" on, as a sanity check, so at the moment deleting one by one is very slow. A checkbox would probably be handy for people using the Export function too.

Brilliant tool though, many thanks. Every time I think of a major refinement it turns out to be in there already!

Stephan Mahieu said...

@Huw

1. It is more or less standard for a lot of add-ons. I agree it does not make very much sense here. I will consider your suggestion.

2. The Shift-Delete key combination in the field is indeed unknown to most users (undocumented feature?) but this add-on will also let you search the complete history for accidentally keyed in passwords. Using the add-on to correct mistakes is (more) convenient for for non-powerusers or those that hardly ever use key-combinations (or can't remember them all).

3. I like to keep the interface as clean as possible so I am hesitant to introduce an extra column. Introducing checkboxes for selecting multiple entries could confuse users, since it introduces an extra or alternative way to select entries which can be counterintuitive.

Glad you like the tool, it is designed with usability in mind.

Anonymous said...

Hello, Maybe I didn't fully understand the capabilities of the tool, but I see something missing: say you want to book train tickets, you fill one field (field_go) with CityA and the other (field_return) with CityB. What if you want to book the retrun trip ? You should be able to store both locations (CityA and B) for each field and select which value to populate the fields with. Today you can do such a thing based only on last or most used. I'm thinking of something like save a "go" configuraion and a "return" one, and then have the possibility to fill from the menu "fill from" -> and a drop list containing "go" and "return" in addition of last and most used ...

Thank you.

Stephan Mahieu said...

The primary function of this add-on is not that of a form-filler. There are many add-ons out there that do a wonderful job at that, so I see no need in incorporating more form-filling capabilities into this add-on.

Matthew Trow said...

Textarea, select fields, checkboxes, radio buttons.

As a web developer, I thought I'd found an excellent replacement for Lazurus:
https://addons.mozilla.org/en-US/firefox/addon/lazarus-form-recovery/

Unfortunately, without the abilty to save ALL types of form information, the usage is limited.

Please correct me if I'm wrong about this, but I can't seen anyway to store fields other than input type text.

Stephan Mahieu said...

Hi Matthew,

This add-on is not primarily meant to be a formfiller, there are already many add-ons out there that do a good job at that.

The main reason I developed Form History Control is to provide the means to inspect and manage the complete form history.
Saving textfields (with exception of textarea) is standard functionality of Firefox. Out of the box all submitted textfields are stored. This add-on gives you control over what is stored and what needs to be cleaned up.

I am however working on a new version which gives you more control so you can choose for which pages you wish to save the form history.
In addition to that, I will also add the ability to save and restore textarea fields in the next major release.

Perhaps, if more requests of this nature keep coming in, I will add the ability to save and restore all types of form information.

Jeremy said...

Hi, this is a great add-on - I've been looking for this functionality for ages! Specifically, the ability to clear my form history *without* also clearing my searchbar history, which I want to be able to keep. I hate the way Firefox keeps both in the same database together.

One suggestion I have is this: the ability to have more than one clean-up schedule. Or at least having two schedules, or two "levels" of clean-up, would be great. I'll explain the purpose:

I'd like to be able to use Form History Control to clean up all forms older than (eg.) 30 days, with the exception of the searchbar history and a couple of other fieldnames which I find useful to keep longer than 30 days. Currently I can add "searchbar-history" and other desired fieldnames to the "Never CleanUp" panel to prevent them from being removed after 30 days - that's simple enough. But at the same time, I also don't need to have those excluded fields kept forever and ever. Eventually they should be removed as well. So it would be great to have a second level of cleanup, which I could set to (eg.) 120 days or whatever, which will then go and clean up those excluded fieldnames. Obviously this would be an optional thing, just for those who'd want to use such a feature!

I suppose you could accomplish this with an additional tab on the Clean Up page, so that you'd have three tabs displayed there: "CleanUp", "Never CleanUp", and "Delayed CleanUp" (or whatever). Entries on "Never CleanUp" really do never get cleaned up (never ever) - this is the current behaviour - and entries on the Delayed CleanUp tab only get cleaned up with the second level of cleaning, eg. after 120 days.

Make sense?! :)

Anonymous said...

what about password protection so ONLY the administrator of the computer can access, edit or delete the history?

Stephan Mahieu said...

Password protection would only protect access from this add-on. You can still use other tools to access the underlying database.
The database is primarily managed by firefox, so encryption is not an option.

vendelin said...

Hi,

Great add-on, I like it very much.

There's one thing I miss: when I open firefox's clear all history data window with Ctrl+Shift+Del and check form history, it may clean up my form data based on this addon's criteria. Is it possible?

Anonymous said...

This plugin doesn't work for me, and I want to remove it. There is no uninstall feature, and the plugin doesn't show up in the about:plugins feature of Firefox. Please, provide info on how to delete this plugin.

Stephan Mahieu said...

After installation and restarting Firefox, this add-on can be disabled or removed with the help of the Add-ons manager (Tools menu in the menu-bar: Add-ons, or if you have the menu-bar disabled: Firefox-dropdown menu: Add-ons)

The about:plugins feature only show system-plugins, not regular add-ons like this one.

Anonymous said...

Is it possible to save consecutive entries in the same text field? I am having intranet site with txtArea_0 and txtArea_1 and I want remember all the entries entered in that field.
Currently it save the last one and remove the one before. I want to keep all entries as this is the best way to save form data in local network site

Stephan Mahieu said...

I can not influence the way input textfields are stored, that is handled entirely by the browser.

In the case of multiline editor fields (like textarea) multiple versions are saved. In order to keep the amount of saved data small, new versions for the same textfield are only saved after a certain time period has gone by or when the content is changed by more then a certain amount of characters. Have a look at the preferences to change these settings.

Anant on Internet said...

Autocomplete does not work on certain forms on certain sites.The site might be telling Firefox to not save form history. As on some email and banking websites. Can a functionality to remember all form history be added overriding restrictions of sites. I think it is my headache to worry about my security. If need be a caution can added in addon UI.

Stephan Mahieu said...

Overriding is next to impossible, saving form history is functionality performed by the browser.

Another way to fix this is to parse each webpage upon loading and remove all autocomplete attributes, but that is not something I am willing to implement in my add-on. As a workaround you could use a bookmarklet before a submit to remove the autocomplete attributes or assign a keyboard shortcut to "save values for all fields" which you can find in the preferences of this add-on (under miscellaneous).

If you want autocomplete attributes removed automatically, consider using an add-on like Greasemonkey which most likely can do the job.

Anonymous said...

Is there a possibility to find different versions of field values and select one to insert it into current open form?

Stephan Mahieu said...

You mean something like selecting an entry from the "Show History" window of Form History Control, and pasting that value back into the current formfield?
That would be relatively easy to do. I like that idea and will try to add that to the next release.

Anonymous said...

Could you please add the ability to remember drop downs. Thanks. Great program!

Dediggefedde said...

I don't know if bug or pending feature:
"div contenteditable=true" won't get recognized as a form field.

As nowadays most WYSIWYG editors use editable divs instead of multiline, it's quite painfull that Form History Control doesn't seem to remember any text I type into those divs.

May it be possible to add this feature? Changing text there can be noticed by the input-Event by Firefox: https://developer.mozilla.org/en-US/docs/Web/Events/input

Stephan Mahieu said...

Thanks Dediggefedd for pointing this out!
With some minor changes I was able to also remember text typed into div fields which have the contenteditable attribute set. This change will be available in the next upcoming release.

Anonymous said...

Hi, just 2 things (actually 1 request and 1 help tip). Help? I'd like FH to capture the data in every form that is somewhat long — not the standard email/name/pw stuff, but the longer forms such as the content in a PHP-scripted forum post *before* it's posted. I just lost a huge, intricate forum post that timed out on me. I generated what I thought was a hard backup using Chris Pederick's Web Developer Addon . . . pull up the html file . . . WTF??? Oh man that pissed me off. 2 paragraphs of data wiped clean. So guide me to your FAQ/Help entry re: automation. I checked to have the option to save manually but if I right-click the forum's FORM BOX to save the raw html it pulls up the manager and I'm uncertain what I need to do after that.

My only request is for the ability to store everything — configuration files, the actual FORM data, everything — to a drive path of my choosing. What a relief to find you!

Stephan Mahieu said...

Hi,

The longer forum-type posts you wish to save, is already handled by the Form History Control addon. Make sure that in preferences/options under 'Editor fields', checkbox 'Enable automatic backup of editor fields and multiline text fields' is ticked. When this option is activated, text in multiline textfields will be stored while you type. Manual save will however not work for these type of multiline fields.
In the main window of this addon, under the tab 'Editor History' you can find all the multiline data that has been stored by this addon.

In order to store everything, configuration and data, to a user defined location you can use the Export function which you can find in the main menu of this addon.

Anonymous said...

Stephan . . . Given the raison d'être for this addon in the first place — confidence that even the longest data you've entered in a form box is stored somewhere — does it not logically follow that you not only know the data is backed up you know where, because the folder you created for this one purpose will be exactly where _you_ would intuitively look for it, not someone else. I never store data on the OS drive. In fact I have an entire drive partitioned as "R" for Recovery, and another as "V" (Vault). I suppose others have the patience to wade through the byzantine labyrinth of "Documents and Settings" or "Program Files" to find their data but I don't! This will be a fantastic Addon if/when a User-defined path is made available for parking the data. Reminding myself regularly to "Export" the data adds another worry (for me). I'll check back periodically. :)

Stephan Mahieu said...

Regular formhistory data is stored by Firefox and not by my add-on, so I do not have any control over how or where this is stored (it is actually stored in a database). All other data stored by my add-on is also stored in a database according to the guidelines opposed by Mozilla.
It is not easy to make the location of the database user-configurable, nor is it safe to do so. Also because it is in a native database format (sqlite), you would have to use special tooling to read the contents.

OwenKL said...

The interface is too tall! I have a netbook (a decision I regret, but I'm stuck with it) which has a screen only 600 pixels high. Your window is considerably taller than that and centered. That means the top (including the grab bar and menu) is off of my screen, and the bottom (including the sizer and any buttons at the bottom) likewise. This leaves me no way to close it or minimize it! Or do anything else those buttons or menus can do!

semicodin said...

٭٭٭٭٭
GREAT Addon Stephan (and an xlnt blog). Re the database location(s) -- If we can't move the directory from FF profile could we instead get a "backup to" option? that way we can do searches and inspect all data without having "nest monster" trying to find it ;) could have restore and import also. :)

Stephan Mahieu said...

You can do an export from within Form History Control (not the csv export, but the first Export option under file menu) and choose whatever you wish to export (data end/or settings) and save it anywhere you like.
The exported file (which is in xml format) can be imported in the same or another firefox instance using the import menu option.

Hope this helps, kind regards, Stephan.

Anonymous said...

Have a check-box column in the Show History view for manually selecting entries to delete

Jozef Kundlak said...

Would it be possible to save all text history related to a single form field on a page? This happens for instance on a webpage where you take a language quiz, where the page retains the same input field, but the questions change... (Sent you a separate email as well).

Anonymous said...

It would be nice if the addon was made multiprocess compatible. Firefox won't enable multiprocess support because this addon is not compatible.

Stephan Mahieu said...

@Jozef:
Normally FHC will only save a single version of anything typed into the same field.
It does however keep multiple versions if the previously stored version is older than a certain amount of time.
In the preferences dialog of FHC, under the Editor Fields tab, you can set the amount of time to 1 minute.
Now if the next save occurs more than 1 minute after the previous save, a new version will be saved for that particular field next to the already existing versions.

Stephan Mahieu said...

@Anonymous Regarding making FHC multiprocess (e10s) compatible:

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 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 https://wiki.mozilla.org/Add-ons/developer/communication)

All things considering 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 new feature has often been very useful for me too.

Anonymous said...

Lazarus had an icon in fields such as this text box I'm typing in, that would serve as a notification to the user that what they were typing was being saved. Quite useful since it didn't support every single text box on every single site. Not sure if your addon has wider support, but a little notifying icon would be reassuring.

Thank you so much for this great addon! Been looking for a Lazarus replacement for so long and no one ever mentioned this :(

Stephan Mahieu said...

Nice suggestion, have been thinking about that too. I will definitely put it on my ToDo list.

Anonymous said...

I see mention of keyboard-shortcuts above but don't see this capability in the new version. Any chance of getting a keyboard-shortcut for "Fill fields with most recent entries"?

Stephan Mahieu said...

There is still some keyboard shortcut support for add-ons using the webextensions API, but the shortcuts have to be hardcoded into the manifest file.
I suppose I can add one or two shortcuts for the purpose of quick filling formfields.

Anonymous said...

I have used Autofill Forms for years and am used to using Alt+j to fill forms, so Alt+j to "Fill fields with most recent entries" would be nice for me but anything would be appreciated. The addon is working great. A few fields refuse to fill but that seems typical for form fillers. Thanks for your work.

Ildar said...

Please add the close button to the popup frame. Sometimes a site pops its own "history" in a frame below the addon's frame. E.g. YouTube.

Ildar said...

Also, why the form data is stored in extension's storage? Isn't it better using FF's own `formhistory.sqlite` ?

Stephan Mahieu said...

Hi Ildar,

Not sure how to reproduce close-button / frame problem. Can you tell me how to reproduce that.

About formhistory.sqlite: The new API no longer facilitates sqlite or access to the builtin formhistory. That is why I have to use another way to store the data.

Ildar said...

About formhistory.sqlite: now it's clear, thanks a lot. Then setting "browser.formfill.enable = OFF" ))
Frame problem:
1. goto youtube.com
2. search "firefox", then search "firefox form"
3. goto youtube.com
4. start typing "fire" in the search bar. Should show two popups one above the other.

Fady said...

Hi,
Thanks for this very precious extension.
I noticed that sometimes there's a bug when trying to restore the before last recent textarea value: It appears in the options list but when clicking on it it shows the last recent value and when going to history, it doesn't shows up.
Is it also possible to show html tags in the restore list ?
Best regards.

Stephan Mahieu said...

@Ildar,
I see what you mean now, this is what is happening:

You have FHC's preference "Override the built-in autocomplete" turned on so the FHC add-on will override the browser built-in autocomplete by setting the HTML input attribute autocomplete to "off" and show a custom dropdown-box based on its own formhistory.
Unfortunately the youtube.com page does exactly the same thing, therefore two dropdown lists are shown.

Showing a close button on a autocomplete dropdown list is not very customary, also clicking that button might also close the youtube dropdownlist.

Stephan Mahieu said...

@Fady,
I have chosen not to show html-tags in the list or context-menu because it takes up a lot of space and makes it harder to choose the value you want. Most of the time it is easier to select the entry by the text alone without the html clutter.

About the bug when trying to restore the before last recent textarea value: I can not reproduce this but I have made some improvements in the upcoming release that might fix this issue.

kstev99 said...

Is it possible to exclude sites? There is a Form for creating a memorial on findagrave.com where you enter the city. For example you start typing Chica and it begings filling the form. You see Chicago, Cook County, Illinois but when you select it you get something totally different like Chicabaya, Magdalena Peñasco Municipality, Oaxaca, Mexico.

FHC is incompatible with find a grave's own auto fill. Is there a way to exclude a site or url?

jimbo1qaz said...

Is it possible to move the "restore editor field" menu items directly into the Form History Control menu, so I don't have to navigate 2 submenus when looking for something to restore? That menu is more useful to me than "Fill fields with most recent entries" etc.

Anonymous said...

Thanks for the shortcut keys. Works great. Worth the wait. Helps me alot for filling forms. Firefox on Xubuntu (Linux).

phlique said...



Edit
Anonymous said...

With respect to all explicite conditions, anything i try, Export don't work. Add-on works very well for all other parts except for Export.
It's very annoying. How to do? Firefox 62.0.3 (64 bits).

Stephan said...

It should work, take a look here:
https://stephanmahieu.github.io/fhc-home/Manual/manual/#export

phlique said...

It finally works very well (all function, Export included). When I begin to use this excellent add-on, I have a strange behavior: no data in the formhistory.xml file, data comes later after some time (a day)!? Why, I don't explain this.
Thank you very much,

Stephan said...

The old version could use the internal Firefox formhistory storage. Newer versions have no longer access to the internal storage and have to create their own. So initially there will be no history, only after using webforms formhistory will become available.

Anonymous said...

I love that we can whitelist/blacklist which sites to save. It would be even better if we could use *.domain.com format on the whitelist/blacklist instead of having to list each subdomain separately.

Sambo said...

Hi Stephan,

Firstly, this is a great add-on and it has saved me many hours of frustration due to lost form data! Thank you for making it!

It would be great if you could customise the columns shown in the history view, both column types and order.

Also, an option (right click or double click) to insert a history item into the current active website field would be very helpful.

I have found that some pages don't re-load 'most recent entries' at all (eg; facebook), so that would be another suggested thing to look into.

Thanks again & keep up the great work! :)

Sam.

Mamat said...

Hi there, I will start by giving a big "thank you" for this addon ! It saved my back a hundred times.
More and more websites use WYSIWYG editors for managing their fields, such as CKEditor, which is a good tool. Form History doesn't seem to work with it, do you have any plans to fix that please ? Or am I doing something wrong ?
I'm a Mozilla Firefox v.74.0.1 user with Form History Control (II).
Mamat

Stephan Mahieu said...

Hi Mamat,

First of all thanks for the compliment!

I am trying hard to support as many of the new or ever changing WYSIWYG editors out there. Form History for CKEditor is still being stored as far as I know, just checked with https://ckeditor.com/docs/ckeditor5/latest/examples/index.html

Can you give me an example where it does not work?

Regards, Stephan.

test said...

Hey Stephan, thnak you so much for answering me so fast. I must say I had a very hard time to find out why it works in your example, and not in my context !
It seems I finally did : there are 2 active versions of CKEditor, version 4 and version 5. Form History Control (II) works fine with the latest, not the previous. You can check it there : https://ckeditor.com/ckeditor-4/demo/
When I use the command "Show fields on the current page", the field is not recognized, which seems to confirm it won't work.
Puzzles me to understand why they keep on developping 2 versions at the same time.
Anyway I'm not sure that it will be possible to upgrade the CKEditor 4 used on the software I'm using. :( But I'll have to try that way anyway. If you ever plan to support CKEditor 4, I would be very grateful.
Best regards, Mamat

Stephan Mahieu said...

It might have something to do with the fact that CKEditor-4 is using an iframe. I will look into this but no promises.

Stephan Mahieu said...

The CKEditor-4 inline editor does not use an iframe and does work, so the iframe is most probably the cause.

Cam said...

Why does the new version need permission to download files and modify download history?

Stephan Mahieu said...

The download permission allows a user to export selected formhistory data entries to the users computer.

I added the permissions FHC requires to the manual:
https://stephanmahieu.github.io/fhc-home/Manual/Permissions/

In the next release this permission will be optional, it will only be requested when the user wants to do an export.

Anonymous said...

I'm using v.1.4.0.6 in SeaMonkey 2.49.6 and FF 52ESR9, in Win XP and Win 7, with the profiles in a non-standard location.

If I try to export the Form History entries and/or the Editor History in SM, the resultant file is empty (I wanted to import it into FF to keep them in sync); in FF it works!

What might be the problem, and what should I do to correct it?

Anonymous said...

A curious detail: The above post was an example of FHC's usefulness: I closed SM before actually posting it -- but, after a reboot, on 'Restore Previous Session", I used FHC to get back the field's content, and it's now posted.

I wanted to use export/import to keep SM and FF in sync for exactly this sort of thing, and it's strange that export is working in FF and not in SM. Perhaps reinstalling the add-on might fix that, or does it indicate there's a problem with my SM profile?

Anonymous said...

Hi, Stephan!

I'm answering my own question: Yes, reinstalling the add-on in SM solved the problem: FHC now can export Editor History in XML files! Sorry I didn't try it before, but this only came to me after posting..

AFAIK, overwriting FF's version of "formhistory.sqlite" with the one from SM, and then importing the exported Editor History XML file, should be enough to make it all work in FF -- or could there be problems?

Thanks a lot for a life-saving app in the FHC add-on, it's been very useful for me (and many others, looking at the other posts); congratulations!

s) Alexyu (I don't have an URL, so had to post as 'anonymous'...

Stephan Mahieu said...

Glad you figured it all out yourself!

Anonymous said...

Thanks for your quick response!

I'm still unsure whether overwriting my FF's version of "formhistory.sqlite" with the one from my SM, and then importing the exported Editor History XML file, should be enough to make it all work in FF -- or could there be problems (due to differences in O.S. and/or the browser variety); what do you think?

Another doubt is about the "import" function: Does it overwrite the current data, or is the imported data added to the existing one? I didn't find any confirmation of either possibility...

Stephan Mahieu said...

Importing the XML should be done from within the add-on. Import will never overwrite only add (you can make a backup beforehand by doing an export from within the add-on itself).
Do not overwrite formhistory.sqlite of recent FF versions, this is a sqlite database that can no longer be be used by add-ons, it is nowadays exclusively in use by FF. Add-ons now use the IndexedDB API.

About importing/exporting from within the add-on, see the Help provided by the add-on: https://stephanmahieu.github.io/fhc-home/Manual/manual/#import-export

Anonymous said...

Hi, Stephan! Thanks for your patience and help!

As I said in my first post, I'm using FHC v.1.4.0.6 in SeaMonkey 2.49.5 and FF 52ESR.9, in Win XP and Win 7, with the profiles in a non-standard location, and I'm keeping these older versions to keep SM and FF in sync over both OS's (that's important to me), so no "recent FF versions" are involved, no Web Extensions at all...

Thanks for the link, but it's focused on the current version of FHC, so probably is not quite adequate for v.1.4.0.6 (but it's very useful otherwise, thanks).

I'm always wary about 'import/sync' processes, because "the devil is in the details". From what you said, I understood that the FHC 'import' is a "merge" function, and that means that no data should be lost by using it, but there might be situations where the merged data file is difficult for the program to process, since it wasn't expecting to find data generated in 2 (or even 4) different 'incarnations' of the program. I haven't commented that my main interest now is in the "Edit History", because that's a constant use fro me, specially in (literally hundreds of) free-form fields, where I would like to re-use previous ones, sometimes in many different pages.

As I understand it, formhistory.sqlite has SM/FF's 'form data', so if I overwrite one with my 'main' one, and just import FHC's 'Edit History' afterwards, the chances of problems should be minimized; do you think so too (I know you probably never had seen quite this setup before, so you may not know beforehand)?

I'll follow your advice and make an 'export' backup of all parts before doing an 'Edit History' import, and then see if any problems arise.

One detail which discourages me from doing 'manual cleanup' on the many versions of the same field editing in time-intervals: Having these several 'cumulative' entries saved is very useful at the time of filling the form but, afterwards, I usually want to delete most or all 'versions' except the final one, and that's easy to do -- but, after every deletion, the window goes back to the latest entry and, if the fields I'm cleaning are much 'lower down', it's a chore finding the exact spot again and again (I had never done clean-up for years, so there's LOTS to do!); is there some way to avoid that?

I also use the "Auto-Fill Forms" add-on, and that's quite complex, so many times I don't even know if some detail is in FHC or in it; sorry if I mixed anything up due to that.

Finally, I haven't seen any option for donations on your site, and would like to show my appreciation; do you have any?

Anonymous said...

While waiting for your response to my June 1 post, I thought some more, specially about when you said "Importing the XML should be done from within the add-on", which might be an answer to my query: Instead of copying the SM 'formhistory.sqlite' over the FF one, if I just use the FHC add-on's export/import functions, they would both be merged (and not only the Edit History) -- and, for good measure, then I could export the resultant merged data and import it into SM, so both would become identical. Is that reasoning correct?

If so, I'm still unsure if such merged data might bring problems to the SM/Ff function and/or FHC. Do you think that might happen?

Stephan Mahieu said...

Hi,

First of all the exported XML is the same in all versions and on all platforms so importing/exporting from FHC is the preferred way.

Importing will never delete any entries, it may however modify existing entries (no of times used, last used date, first used date). Just to be safe you can do an export first before importing and use that as a backup.

After an import you can do an export and use that to update (sync) other versions (SM, FF, ..) on arbitrary Operating Systems. That is the beauty of XML in this case :-).

Regarding donations, its well hidden :-) See here: https://stephanmahieu.github.io/fhc-home/about/#show-your-appreciation

Nothing makes me more happy than knowing that this plugin is useful and valuable to you. Showing your appreciation encourages me to continue developing and improving the Form History Control add-on.

Stephan Mahieu said...

About manual cleanup:
you can select multiple entries by holding CTRL while you click. After selecting multiple entries the remove button will delete all selected entries.

Anonymous said...

Hi, Stephan!

Thanks for the add-on and your help.
PayPal contrib sent (seeing it in local currency made it seem bigger).

FHC has been a very useful Extension; I can't remember a time when I didn't use it, so much so that I can't imagine Mozilla's Form History without it.

I also tend to mix it up with another complementary add-on, "AutoFillForms", which also is helpful (but is nightmarishly comlicated). I don't use them all quite like as intended, but they're very important for m. Is there a FHC-like extension for MS Edge?

Thanks a lot for your clear and well-explained reply about the export/import/export process I told you about. I now feel much more confident in using it that way.

One final point: Yes, I knew that "you can select multiple entries by holding CTRL while you click; after selecting multiple entries the remove button will delete all selected entries"; I use it constantly. My problem is that, after every deletion (even 'mass deletions' using CTRL), the window goes back to the first (latest) entry and, if the fields I'm cleaning are much 'lower down', it's a chore finding the exact spot again and again (I had never done clean-up for years, so there's LOTS to do!); is there some way to avoid that?

Post a Comment