Personally, off the top of my head, I don't want to go here. People either want suggestions or they don't (in which case they kill the whole thing). I think freceny is good for those people - the algorithm helps ensure the most relevant items - so it would have to be inactive. It would be another thing to maintain - do you know how many times mozilla tweak and f*k with the urlbar? Answer: all. the. time.
That said if it was one pref, and we added inactive with warnings, then it would actually suit people like me - where I want zero dropdowns but would like keyword searches from the urlbar
From 1st link:
// the (maximum) number of the recent visits to sample when calculating frecency
pref("browser.frecency.numVisits", 10);
It seems to affect the urlbar list.
That one pref that he quoted has to do with some cache half-life experiments and nothing to do with the places.frecency.* prefs. The user.js already clears history on shutdown by default and we shouldn't mess with people's bookmarks IMHO, so no need to go there.
browser.frecency.numVisits doesn't exist anymore Atavic (that link is from 2008, so much has changed since then). And now I've had a chance to read TheWindBringeth's comments, what earthlng said is true.
I really do not want to mess with this. IF someone has one-or-more suggestion types on for keyword search engines, and IF that someone has maxRichResults at 0 to hide suggestions, and IF that person clears history as per the user.js, then it's not too often something will show. And if they did, a FF restart or a clear history will do the trick
Messing with the relevancy of bookmarks, typed urls, clicked links etc - all those weight and bonus and type points - I am sure I could kill frecency, but it's really not necessary. A hardened browser can just flat out kill suggestions, and that's what matters.
Thanks Atavic. I know you were not suggesting we actually do this, just adding some info in that other thread. It was worth a look. Closing as WONTFIX
frecency (frequency + recency)
Did some search and browser.cache.frecency_experiment -1 does not disable anything.
if at -1, no experiment is run and we use the preferred value for frecency (6h)
See: bugzilla 986728
So I keep a low fingerprint with:
browser.cache.frecency_experiment 4
*.frecency.*Bonus 0
*.frecency.*Weight 1
The first value of 4 gives low frequency, while
browser.cache.frecency_half_life_hours 6 is a decay-time and an high value means low recency
browser.cache.frecency_experiment is a dead pref since FF59. It's even listed in the user.js under 9999
@earthlng
browser.cache.frecency_experiment is a dead pref since FF59. It's even listed in the user.js under 9999
I believe you since you're generally on top of things but how did you learn this? I must be 'doing it wrong' or something since I typically run entries through DXR to check if they're still listed. If so then I've assumed they're still active, and vice versa. Is this not necessarily true?
Tell me how you've learned that browser.cache.frecency_experiment has been dead since v59? It's still listed on mozilla-central here and here and on mozilla-release here.
Not challenging what you're saying or anything, just genuinely curious how you find out such things.
how did you learn this?
I must have searched for it on DXR and noticed it's not used anymore.
The 3 places you linked are the pref definitions. That's why I wrote "dead pref": the pref still exists but the code that used it was removed, they just forgot to remove the pref.
Since it was removed in FF59 you have to go back to esr52 on DXR to see what it looked like when it was still used. compare
https://dxr.mozilla.org/mozilla-esr52/search?q=frecency_experiment and
https://dxr.mozilla.org/mozilla-esr60/search?q=frecency_experiment
^^ FYI from that point on it's easy to find the relevant bugzilla by
in this case there were only 9 changes to that file since esr52 and the most recent change is "Remove the HTTP cache half-live experiment". It's not always that easy but you get the idea
On some forks this entry is active.
@earthlng Thanks for breaking it down. Your thoroughness and follow-through is pretty damn inspiring.
@grauenwolfe you're welcome. Thanks for the compliment!
Most helpful comment
^^ FYI from that point on it's easy to find the relevant bugzilla by
in this case there were only 9 changes to that file since esr52 and the most recent change is "Remove the HTTP cache half-live experiment". It's not always that easy but you get the idea