Closed Bug 406422 Opened 17 years ago Closed 16 years ago

Globally decay adaptive input history to allow for new entries

Categories

(Firefox :: Address Bar, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 3.1a1

People

(Reporter: Mardak, Assigned: Mardak)

References

Details

Attachments

(1 file)

New entries start at 1, so decaying to anything less than 1 OnQuit will give the new entries a better chance at affecting results (and surviving when we remove infrequently used input histories).
Attached patch v1 (deleted) — Splinter Review
"Rebalance" all results by shrinking them by 99%. This will be called OnQuit which will trigger the paranoid expiration.
Assignee: nobody → edilee
Status: NEW → ASSIGNED
Comment on attachment 291076 [details] [diff] [review] v1 Decaying once-used selections (use_count of 1) would be helpful for new entries to show up that enter with a value of 1 when showing adaptive results. Additionally, this will help slowly decay previously-used adapted results to allow for new adapted results.
Attachment #291076 - Flags: review?(dietrich)
Flags: wanted-firefox3.1?
Comment on attachment 291076 [details] [diff] [review] v1 looks good, r=me
Attachment #291076 - Flags: review?(dietrich) → review+
I'll probably bump up the decay to .9 instead of .99. That will take ~20 times for a once-used adapted result to drop to .1 whereas .99 would still be around .36 after 100 times. This is more interesting for the more commonly used adaptive results for allowing new adapted results showing up faster. Positive reinforcement of selecting the results will keep the adapted results up.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.1a1
I think this made autocompleting worse for me over the last few days. While the first result used to be the one that I looked for very often, it's now the second or third result more frequently. Maybe .9 instead of .99 was a little drastic.
Any examples in particular? The decay is applied to all inputs, so anything that was ranked higher will stay ranked higher.
Right, it's applied to all use counts, so I can't really explain what I was seeing. Maybe there was another change that I don't know of?
Flags: wanted-firefox3.1? → wanted-firefox3.1+
Verified FIXED using: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080911020347 Minefield/3.1b1pre Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20080911105329 Minefield/3.1b1pre -and- Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1b1pre) Gecko/20080911135921 Minefield/3.1b1pre, using Edward's testcase: Make a new profile open the location bar drop-down and select the 3rd entry (A) (open the drop down and that entry (A) should be 1st) restart the browser open the drop down and select the new 3rd entry (B) (B) is now higher in the list than (A) open drop down and select (A) open drop down and select (B) (B) should still be higher than (A) which I'll polish up just a tad and land in Litmus for 3.1
Status: RESOLVED → VERIFIED
Flags: in-litmus?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: