Closed Bug 390158 Opened 13 years ago Closed 11 years ago

Hook up new satchel pref(s) to the preferences window (and clear data?)

Categories

(SeaMonkey :: Preferences, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
seamonkey2.0

People

(Reporter: standard8, Assigned: iann_bugzilla)

References

(Blocks 2 open bugs)

Details

(Keywords: fixed-seamonkey2.0)

Attachments

(1 file, 1 obsolete file)

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.
Depends on: prefpane_migration
Depends on: 416233
(Filter "spam" on 'prefs-nobody-20080612'.)
Assignee: prefs → nobody
QA Contact: prefs
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.
Flags: blocking-seamonkey2?
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!
Depends on: 436934
Duplicate of this bug: 459052
browser.formfill.expire_days is another satchel pref that should be available ny itself in UI.
Blocks: 436934
No longer depends on: 436934
Duplicate of this bug: 504865
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.
Assignee: nobody → iann_bugzilla
Status: NEW → ASSIGNED
Attachment #397638 - Flags: superreview?(neil)
Attachment #397638 - Flags: review?(mnyromyr)
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.
Attachment #397638 - Flags: superreview?(neil) → superreview+
Attachment #397638 - Flags: review?(mnyromyr) → review+
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
Attachment #397638 - Attachment is obsolete: true
Attachment #400177 - Flags: superreview+
Attachment #400177 - Flags: review+
Attachment #400177 - Flags: approval-seamonkey2.0?
Blocks: 423281
Attachment #400177 - Flags: approval-seamonkey2.0? → approval-seamonkey2.0+
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
Attachment #400177 - Attachment description: Add formfill prefs to history pane patch v0.1a → Add formfill prefs to history pane patch v0.1a [Checkin: Comment 18]
Flags: blocking-seamonkey2.0?
Ian, is there anything left to do here or can we resolve this bug?
Blocks: 516511
(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
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.0
Depends on: 518509
You need to log in before you can comment on or make changes to this bug.