Following the switch over to satchel, we need to hook up browser.formfill.enable in the preferences somewhere. We probably also want to hook up an option for clearing the stored data, like FF has.

(Filter "spam" on 'prefs-nobody-20080612'.)

Prior to the switch to satchel, there was UI that enabled a user to edit his profile's form fill-in data. Now, as far as I know, there is no such UI. The amount of stored data grows and grows, and there is no way (known to me) to remove items from that set of stored data. It has been this way for almost a year now. (I'd be happy to be wrong about this.) IMO, SM2 definitely needs to give the user control over his stored form data.

Temporary workaround: Install SQLiteManager mod for SeaMonkey <http://xsidebar.mozdev.org/modifiedmisc.html#sqlitemanagerhttp://xsidebar.mozdev.org/modifiedmisc.html#sqlitemanager> and edit the formhistory.sqlite file.

You can however clear one form autocomplete item from the list at a time by highlighting it and pressing Shift+Delete.

(In reply to comment #4) > You can however clear one form autocomplete item from the list at a time by > highlighting it and pressing Shift+Delete. Neil, Perhaps you meant that in some context other than the form in which the fields are being filled in? The following steps (which you seem to be suggesting) certainly do NOT cause the selected entry to be deleted. 1. Go to a form page 2. Start to type in a value into a field 3. See a drop-down list of choices 4. Select one of those choices 5. Press Shift-Delete. For example, in this (or any) bugzilla bug page, go to the bug number field (by the "find" button at the top of the page) and type a single character, either "1" or "2". A list of previously entered numbers appears in a drop down list. Select one from the list. As soon as you highlight it, the value is placed into the text box and the drop-down list disappears. Now, press shift+Delete, or if you like, highlight the text in the text box and press shift+Delete. This has no effect on the saved values for that field.

I'm pretty certain that, in comment 3, Phillip meant to enter this URL: http://xsidebar.mozdev.org/modifiedmisc.html#sqlitemanager

What Neil probably meant is go to the form field, press the down arrow (or type something, so that dropdown appears), press the down/up arrows until the entry you want is highlighted. You can press delete or shift+delete there, and the entry is gone from both the dropdown and the satchel database. Of course, with the "Clear Private Data" function, you also delete the whole form history database if you want.

I tried the SQLite manager mod extension. Found I had almost 6000 entries saved. I was able to delete over half of them, although it was a bit tedious because you cannot delete more than about 80 a time (UI limitation), and you must re-sort and re-scroll the table after each deletion. Still, this is infinitely better than nothing! Phil, is there a bug DB for that extension? By examining the table, I found that every time I submit a form, all the fields, including hidden fields and fields whose values are always set programmatically by JavaScript (not user entered) are stored in the table. This table is a high value target for attackers, since it tends to contain all info (sensitive or not) ever entered into any form.

> Phil, is there a bug DB for that extension? It's somewhere here http://code.google.com/p/sqlite-manager/ I haven't been keeping up with the latest versions of that extension, so your problem might have been fixed in the latest official releases. Certainly the author has been hyperactive in fixing bugs and adding features.

In fact the latest version are compatible with SeaMonkey 2.0a!

browser.formfill.expire_days is another satchel pref that should be available ny itself in UI.

This patch: * Adds a default setting for browser.formfill.expire_days. * Adds exposes the preferences for browser.formfill.enable/expire_days on the history pane. * Updates the help page to reflect the change in the history pane.

Comment on attachment 397638 [details] [diff] [review] Add formfill prefs to history pane patch v0.1 >+ <textbox id="formfillDay" >+ type="number" >+ size="4" >+ preference="browser.formfill.expire_days"/> Nit: needs aria-labelledby (sp?) Oh wait, the whole pane needs it. Never mind.

Comment on attachment 397638 [details] [diff] [review] Add formfill prefs to history pane patch v0.1 >diff --git a/suite/common/pref/pref-history.xul b/suite/common/pref/pref-history.xul While you are touching this dialog, would you agree that the "<separator class="thin" />" in line 93 is just nonsense? If so, please remove it. ;-) >diff --git a/suite/locales/en-US/chrome/common/help/cs_nav_prefs_navigator.xhtml b/suite/locales/en-US/chrome/common/help/cs_nav_prefs_navigator.xhtml >+ <li><strong>Enable form and search history</strong>: Select this to let >+ &brandShortName; to keep a history of the forms you fill in and the >+ searches you do.</li> 1 2 2 much? ;-) One thing I find odd here is that browsing history and location bar history do have a "Clear" button, but forms history has not. This looks rather inconsequent and illogical and should be worth an extra bug. ;-)

Requesting a= for low risk patch

Comment on attachment 400177 [details] [diff] [review] Add formfill prefs to history pane patch v0.1a [Checkin: Comment 18] http://hg.mozilla.org/comm-central/rev/e010e16d7983

Ian, is there anything left to do here or can we resolve this bug?

(In reply to comment #19) > Ian, is there anything left to do here or can we resolve this bug? Just to remind myself that there was a bug to be logged on having a consistency for clear button in the history prefs pane - see bug 516511