User:Sspitzer/GlobalFrecency
notes
1)
unvisited bookmarks are no longer hidden, but unvisited livemark items are. this happens in nsNavBookmarks::InsertBookmark(), where we call UpdateFrecencyAndHiddenForBookmark(), but only if the parent is not a livemark
2)
when you remove a bookmark, should the frecency change for that place? yes, it should, as we gave weight to bookmarks. RemoveItem() calls UpdateBookmarkHashOnRemove() with the place id, so we do this work there. Note, if you remove a folder, we will eventually call RemoveItem(), so that's how this works with removing folders.
3)
spin off bug:
// UpdateBookmarkHashOnRemove() does a sanity check using // IsBookmarkedInDatabase(), so it might not have actually // removed the bookmark. should we have a boolean out param // for if we actually removed it, and use that to decide if we call // UpdateFrecency() and the rest of this code?
4)
on calculating frecency, if we don't know ahead of time, we need to check that for a place id, if it is bookmarked, but not a livemark. see CalculateFrecency() [not CalculateFrecencyInternal()]
5)
spin off bug:
upon moving a bookmark, update the frecency. for unvisited bookmarks, this bumps the frecency, because we use PR_Now() as the pseudo visit, which is desired, as we're expressing interest. For visited bookmarks, it may age the bookmark and lower frecency. Is that desired? for now, punt on this and for annoations for updating frecencies.
5)
issue: if when autocompleteing, we will prefer moz_place title over bookmark title, and so when showing match, we will show that one. because of the fix for bug #407292 – When adding a bookmark with no title, we should use the uri as the title, you might get the uri as the title if it matches the user text, as we prefer it.
6)
spin off bug:
we recalc twice on idle, one for invalid and one for old frecencies. need marco's last_visit_date change to make old work right, or do a subquery until then. right now, we are going to recalc the same places over and over. (if we do a sub query, watch out for performance)
recalculating for invalid (frecency == -1) is for firefox 2 / 3b2 -> b3
recalculating for old frecencies is for the ebay problem (https://bugzilla.mozilla.org/show_bug.cgi?id=394038#c19)
to solve the ebay problem, we should also recalc the moz_places with high frecency and "old" last visit date. (In another patch, marco has added last visit date to moz_places, which will make the query we need more efficient as we don't have to join against moz_historyvisits)
If something has a recent last visit date, then we recently recalculated frecency, so the frecency would be accurate.
If something has a low frecency and an old last visit date, recalculating would only lower the frecency (and low frecency wouldn't be hurting our autocomplete results.)
But if something has a high frecency and an old last visit date, recalculating the frecency would lower the frecency, which would solve the ebay problem.
7)
when updating places with frecency of -1, we call CalculateFrecency(), which will check if the place is a livemark item (only), and if so, use PR_FALSE for is bookmarked. we need to do all this so that upon calculating frecencies for previously hidden livemark items, we don't unhide them. (They should come back with frecency of zero if they were never visited.)
8)
in previous versions of the patch, I had hidden <> 1 in the check for invalid frecencies. we don't need to (nor want to) limit recalculations to non hidden. what we currently do is look for anything with frecency of -1, and recalc (on idle). if frecency goes to > 0, we can unhide it. this will cause old, hidden bookmarks to be unhidden and start showing up in url bar autocomplete, yet keep hidden, unvisited livemark items hidden.
note, we have had issues in the past where unvisited bookmarks are hidden. (see bug #369887)
with a new bookmark, we create a moz_place for it, with hidden = 1. if you were to visit that bookmark, we would set hidden to 0, even if you later cleared all visits.
for new bookmarks, we will be calculating the frecency (and unhiding) when we call InsertBookmark()
todo
x)
MigrateV7Up() may need to call "rv = prefs->SetIntPref(PREF_BROWSER_LEFTPANEFOLDERID, -1);"
covered by another bug, but we need to fix it before landing.
x)
// when we created the moz_place entry for the new bookmarks, hidden was 1,
// so frecency was 0. now update the frecency for this item
// XXX unless this is a livemark?
printf("XXX %lld UpdateFrecencyAndHiddenForBookmark\n", childID);
a) TRANSITION_BOOKMARK
b) prefs to make the pig tunable
d) what weight should transistion download have?
x)
optimization, if not bookmark and no visit count, bail out early from frequency calculation?
x)
make sure that we aren't doing too much work when a livemark gets updated, due to removing from hash
x)
first time migration delay: from adding column with -1
x)
first time, all bogus (need to take the top <x> and recalc), on migration and import from fx 2
x)
impact of hidden for bm: note, bm search now in open location and pref page
x)
on any visit, recalc
x)
on any erase visit, recalc
x)
when do I reval places I don't revisit? (expiration might be a long time). page with 10 visits in 1 day will have high frecenct until I recalc
x)
cpu usage
x)
pref for chunk size
x)
make sure we stop searching once we hit max results?
x)
should drop down be frecency or visit date?
x)
we do need to recalculate frecency on history import?
x)
recalc on bm import / restore