Actually after a private clear data "most visited" query is still populated by unvisited bookmartks, that is because it rely on visit_count that is not always correcdt and is not resetted on cpd (Bug 416313). We can't use the real count(*) from moz_historyvisits since it would make the query too slow on large histories (i'm testing with about 130000 entries at the moment). this query try to exclude at least items that don't have any visit. From my tests we loose about 2-4ms, a more than acceptable timing, but we could make this faster (but less correct) removing the check for visit_type NOT IN (0,4). final query for timings tests is: SELECT h.id, h.url, h.title, h.rev_host, h.visit_count, (SELECT visit_date FROM moz_historyvisits WHERE place_id = h.id AND visit_type NOT IN (0,4) ORDER BY visit_date DESC LIMIT 1) , f.url, null, null FROM moz_places h LEFT OUTER JOIN moz_favicons f ON h.favicon_id = f.id WHERE h.id IN (SELECT p.id FROM moz_places p WHERE p.hidden <> 1 AND EXISTS (SELECT id FROM moz_historyvisits WHERE place_id = p.id AND visit_type NOT IN(0,4) LIMIT 1) ORDER BY p.visit_count DESC LIMIT 10) ORDER BY h.visit_count DESC ; or without visit_type check SELECT h.id, h.url, h.title, h.rev_host, h.visit_count, (SELECT visit_date FROM moz_historyvisits WHERE place_id = h.id AND visit_type NOT IN (0,4) ORDER BY visit_date DESC LIMIT 1) , f.url, null, null FROM moz_places h LEFT OUTER JOIN moz_favicons f ON h.favicon_id = f.id WHERE h.id IN (SELECT p.id FROM moz_places p WHERE p.hidden <> 1 AND EXISTS (SELECT id FROM moz_historyvisits WHERE place_id = p.id LIMIT 1) ORDER BY p.visit_count DESC LIMIT 10) ORDER BY h.visit_count DESC ;

Comment on attachment 302105 [details] [diff] [review] patch Ondrej, could you give some timing on your big places.sqlite please?

for reference this is the old query: SELECT h.id, h.url, h.title, h.rev_host, h.visit_count, (SELECT visit_date FROM moz_historyvisits WHERE place_id = h.id AND visit_type NOT IN (0,4) ORDER BY visit_date DESC LIMIT 1) , f.url, null, null FROM moz_places h LEFT OUTER JOIN moz_favicons f ON h.favicon_id = f.id WHERE h.id IN (SELECT p.id FROM moz_places p WHERE p.hidden <> 1 ORDER BY p.visit_count DESC LIMIT 10) ORDER BY h.visit_count DESC ;

Comment on attachment 302105 [details] [diff] [review] patch With my biggest database (69MB made up just of places and visits) the more correct query takes about 20% time more. What is less than 1ms difference.

Comment on attachment 302105 [details] [diff] [review] patch dietrich, we could take this while waiting to see what to do with visit_count. Having "most visited" returning items after a clear private data gives users a sense of "bogus" and lack of privacy.

Comment on attachment 302105 [details] [diff] [review] patch looks good, thanks for measuring performance first. r=me. drivers: low impact fix for perceived privacy issue, and correctness.

Checking in toolkit/components/places/src/nsNavHistory.cpp; /cvsroot/mozilla/toolkit/components/places/src/nsNavHistory.cpp,v <-- nsNavHistory.cpp new revision: 1.247; previous revision: 1.246 done

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv