STR: 1. Start firefox with new profile 2. Show bookmarks sidebar 3. Expand 'Bookmarks Toolbar' and 'Most Visited' 4. Visit some sites (and/or visit https://translate.google.com and type any character for convenience) for filling up 'Most Visited' tree. 5. Do 'Delete Page' (or 'Forget About This Site') in 'Most Visited' AR: Items are decreased. Overflowed items don't appear. ER: Overflowed items appear. workaround(?): Close sidebar and reopen it. mozregression: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d4d7e793ebe8d7764b5ad46736fb923afa005a9c&tochange=5bd6b0a28492aad563e0804da8996f73e6102bd1

atlanto, can you check your regression range for this? I've reproduced this as far back as Firefox 57.0 (release), I'm not sure this is a regression...

I'm sure.

The best I can see here is that there's some sort of strange caching going on. If you have more than 10 items for the most visited, and then delete some from that top list, you don't get any more showing up. This seems to be the case from before the regression here - the query doesn't update itself when an item is removed from its visible list. This case seems to be: - 10 items displayed, - a couple more added, - a couple deleted Previously this would cause the original 10 items to be redisplayed, but now that doesn't happen. Note that pre-regression, I don't think it would add more items even if they hadn't been displayed (you'd need to restart FF). So I think the fundamental issue is the query not re-updating itself when one of the items it shows is removed. The regression is just some possible weirdness associated with that. Although I'm not 100% sure, there's something strange going on with reproducing this. Marco, any ideas here?

Currently on delete we don't re-query, and as such new entries are not added, we just remove old entries. This regressed with bug 1089691 because the old API was causing a batch update notification, that in the end caused a complete new query to run and refresh contents. The new API doesn't have a batching notification, and exposes this lack of update. We should probably consider the update a QUERYUPDATE_COMPLEX (and maybe we could use this occasion to merge QUERYUPDATE_COMPLEX and QUERYUPDATE_COMPLEX_WITH_BOOKMARKS) and handle the update differently on history removal.

note what we do on history insertion: https://searchfox.org/mozilla-central/rev/0640ea80fbc8d48f8b197cd363e2535c95a15eb3/toolkit/components/places/nsNavHistoryResult.cpp#138