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)
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. make this a spin off bug.
5)
issue: if when autocompleteing, we will prefer moz_place title over bookmark title, and so when showing match, we will show that one. this because of the fix for bug #407292 – When adding a bookmark with no title, we should use the uri as the title, you might be weird due to bug:get the uri as the title if it matches the user text, as we prefer it.
because of 407292 – When adding a bookmark with no title, we should use the uri as the title6)
6we 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)
we recalc twice on idle, one for invalid and one for old7)
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 marco's last_visit_date change to make old work rightdo all this so that upon calculating frecencies for previously hidden livemark items, or do a subquery until thenwe don't unhide them. (They should come back with frecency of zero if they were never visited.)
7) when updating things 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)
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)
