None of the bookmarks on my bookmarks toolbar which I visit multiple times a day are mentioned.

Seth: can you help resolve this for us?

try using this query in sqlite explorer or similar, it should return "about" the same results (the query from places excludes also feeds) SELECT COALESCE(b.title,h.title), h.visit_count from moz_bookmarks b JOIN moz_places h ON h.id = b.fk WHERE b.type = 1 GROUP BY h.id ORDER BY h.visit_count DESC LIMIT 10 if this is returning the same result (and visit_count is high) the problem could be connected to some auto-refresh url

> Seth: can you help resolve this for us? investigating. I'm wondering if the recent move of the personal toolbar (for bug #387746) could be related? for an existing profile, our query for this special places folder is: place:folder=2&folder=4&queryType=1&sort=8&excludeItemIfParentHasAnnotation=livemark%2FfeedURI&minVisits=1&maxResults=10 (for me, 2 == bookmarks root, 4 == tag folder) I'll check if this query covers the personal toolbar

> (for me, 2 == bookmarks root, 4 == tag folder) sorry, 4 == unfiled root. in the old query, we had folders 2 (bookmark menu) and 4 (unfiled), and we did this to exclude 3 (tags). but, the personal toolbar has been moved out, and is not longer a child of the bookmarks menu, so items under it are excluded for this query. You can see that mano made a similar fix for bug #404446, where to fix search we now need to explictly specify all three folders: - tree.applyFilter(aSearchString, true, + tree.applyFilter(aSearchString, [PlacesUtils.bookmarksMenuFolderId, PlacesUtils.unfiledBookmarksFolderId, PlacesUtils.toolbarFolderId]); This is fall out from bug #387746, and we need to do two things: 1) fix the queries in initPlacesDefaultQueries() in browser.js so that for new profiles, we also search toolbarFolderId 2) for existing profiles, we need to migrate these queries. note, I think we also have a bug about fixing the wording (so it might make sense to write the query migration code all at once.)

for the migration issue, see also bug #399477 (where we want to fix the wording of the folder and the queries.)

> 2) for existing profiles, we need to migrate these queries. note, I think we > also have a bug about fixing the wording (so it might make sense to write the > query migration code all at once.) I've spun that off to bug #405231, as we should at least wait for the new wording for bug #399477 before migrating.

Comment on attachment 290028 [details] [diff] [review] patch (for the new profile scenario) r=mano, thanks.

fixed. Checking in browser.js; /cvsroot/mozilla/browser/base/content/browser.js,v <-- browser.js new revision: 1.901; previous revision: 1.900 done note, this is only fixed for new profiles, created after this fix. Bug #405231 tracks fixing this for existing profiles. ria and dave: as power users, you could manually force us to create another Places folders (using the hidden browser.places.createdDefaultQueries pref) to verify the fix with your existing profile.

V. FIXED by resetting the pref

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