406422 - Globally decay adaptive input history to allow for new entries

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect)

Description

[Ed Lee :Mardak]

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).

Comment 1

[Ed Lee :Mardak]

Attachment: v1

"Rebalance" all results by shrinking them by 99%.

This will be called OnQuit which will trigger the paranoid expiration.

Comment 2

[Ed Lee :Mardak]

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.

Comment 3

[Dietrich Ayala (:dietrich)]

Comment on attachment 291076 [details] [diff] [review]
v1

looks good, r=me

Comment 4

[Ed Lee :Mardak]

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.

Comment 5

[Ed Lee :Mardak]

http://hg.mozilla.org/mozilla-central/index.cgi/rev/18ca8c440524

Comment 6

[Dão Gottwald [:dao]]

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.

Comment 7

[Ed Lee :Mardak]

Any examples in particular? The decay is applied to all inputs, so anything that was ranked higher will stay ranked higher.

Comment 8

[Dão Gottwald [:dao]]

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?

Comment 9

[Stephen Donner [:stephend] Not actively reading bugmail]

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

Comment 10

[Stephen Donner [:stephend] Not actively reading bugmail]

in-litmus+: https://litmus.mozilla.org/show_test.cgi?id=7035