234
edits
User:Sspitzer/GlobalFrecency: Difference between revisions
Jump to navigation
Jump to search
User:Sspitzer/GlobalFrecency (view source)
Revision as of 21:24, 29 December 2007
, 29 December 2007no edit summary
No edit summary |
No edit summary |
||
| Line 11: | Line 11: | ||
3) | 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) | 4) | ||
| Line 25: | Line 27: | ||
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? | 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 | for now, punt on this and for annoations for updating frecencies. make this a spin off bug. | ||
5) | 5) | ||
issue: if when autocompleteing, we will prefer moz_place title over bookmark title, and so when showing match, we will show that one. | 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) | |||
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) | |||
7) | |||
need | 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) | note, we have had issues in the past where unvisited bookmarks are hidden. (see bug #369887) | ||