Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Form history should record creation/usage timestamps.

RESOLVED FIXED in mozilla1.9.1b2

Status

()

Toolkit
Form Manager
RESOLVED FIXED
9 years ago
5 years ago

People

(Reporter: Dolske, Assigned: Dolske)

Tracking

({fixed1.9.1, verified1.9.0.9})

Trunk
mozilla1.9.1b2
fixed1.9.1, verified1.9.0.9
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Assignee)

Description

9 years ago
Form history entries should be stored with a timestamp indicating when they were last used. This is needed for a few features of interest:

1) "Forget everything I did in the last hour"
2) Enable expiring old form history automatically
3) Awesomebar-like functionality for form fields could use this for frecency.

The first step to these features is storing the timestamps... #2 and #3 would want a last-used timestamp. #1 would need a when-created timestamp (we wouldn't want to clear out pre-existing entries)
Flags: blocking1.9.1+
(Assignee)

Comment 1

9 years ago
Created attachment 346414 [details] [diff] [review]
Patch v.1 (WIP)

Compiles but completely untested.
(Assignee)

Comment 2

9 years ago
Created attachment 346791 [details] [diff] [review]
Patch v.2
Attachment #346414 - Attachment is obsolete: true
Attachment #346791 - Flags: review?(mconnor)
Whiteboard: [has patch][needs review mconnor]

Updated

9 years ago
Attachment #346791 - Flags: review?(sdwilsh)
Attachment #346791 - Flags: review?(mconnor)
Attachment #346791 - Flags: review+
Comment on attachment 346791 [details] [diff] [review]
Patch v.2

r=sdwilsh
Attachment #346791 - Flags: review?(sdwilsh) → review+
Whiteboard: [has patch][needs review mconnor] → [has approval]
(Assignee)

Comment 4

9 years ago
Pushed changeset b02a1924b231.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [has approval]
(Assignee)

Updated

9 years ago
Depends on: 464858
Blocks: 464947
Keywords: fixed1.9.1
Created attachment 355312 [details]
formhistory.sqlite which breaks search bar

Justin, today I got a notice from a friend that his search bar isn't working anymore with Firefox 3.0.5 after he accidentally selected a profile for a test with Firefox 3.2a1. After some tests we identified the formhistory.sqlite to be the cause for the problem and reduced this database to a minimized test case. Now it only contains one single entry. I tested Firefox 3.1 with this formhistory.sqlite and it works fine after this patch was checked into the tree between 081113 and 081114.

Is there any way to get this into the 1.9.0 branch too? This patch looks a bit too heavy, so I wanted to ask you first before filing a new bug on that. What do you think?
(Assignee)

Comment 6

9 years ago
Yeah, known problem, but I haven't filed the bug. :(

Satchel needs the same DB upgrade/downgrade logic as bug 467463 adds for pwmgr, and the column shouldn't be created with "NOT NULL".
(Assignee)

Updated

9 years ago
Depends on: 472064
(Assignee)

Comment 7

9 years ago
(filed bug 472064)
(Assignee)

Updated

9 years ago
Blocks: 483096
Justin, even with bug 472064 fixed the formhistory.sqlite from my comment 5 breaks the search bar with Firefox 3.0.7 on OS X. Shouldn't that have been fixed?
(Assignee)

Comment 9

9 years ago
No, that's expected but not fixable.

Profiles created with 3.1/3.2 builds between when this bug landed (Nov 11) and when bug 472064 landed (Jan 22) will have formhistory files unusuable with Firefox 3.0. See bug 472064 comment 5.
(Assignee)

Comment 10

9 years ago
This fix landed on 1.9.0.8 as part of bug 483096.
Keywords: fixed1.9.0.8
Verified through bug 483096 for 1.9.0.8.
Keywords: fixed1.9.0.8 → verified1.9.0.8
You need to log in before you can comment on or make changes to this bug.