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)
Firefox
Address Bar
Tracking
()
VERIFIED
FIXED
Firefox 3.1a1
People
(Reporter: Mardak, Assigned: Mardak)
References
Details
Attachments
(1 file)
(deleted),
patch
|
dietrich
:
review+
|
Details | Diff | Splinter Review |
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).
Assignee | ||
Comment 1•17 years ago
|
||
"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
Assignee | ||
Comment 2•17 years ago
|
||
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)
Comment 3•16 years ago
|
||
Comment on attachment 291076 [details] [diff] [review]
v1
looks good, r=me
Attachment #291076 -
Flags: review?(dietrich) → review+
Assignee | ||
Comment 4•16 years ago
|
||
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.
Assignee | ||
Comment 5•16 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.1a1
Comment 6•16 years ago
|
||
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.
Assignee | ||
Comment 7•16 years ago
|
||
Any examples in particular? The decay is applied to all inputs, so anything that was ranked higher will stay ranked higher.
Comment 8•16 years ago
|
||
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?
Updated•16 years ago
|
Flags: wanted-firefox3.1? → wanted-firefox3.1+
Comment 9•16 years ago
|
||
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?
in-litmus+: https://litmus.mozilla.org/show_test.cgi?id=7035
Flags: in-litmus? → in-litmus+
Assignee | ||
Updated•6 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•