User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8) Gecko/2007091211 GranParadiso/3.0a8 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8) Gecko/2007091211 GranParadiso/3.0a8 Recently I've compressed my Firefox history using mozStorage Explorer executing some SQL queries on places.sqlite database. The most common was DELETE FROM moz_places WHERE url LIKE "%somesite.com%"; After that I cannot manage my bookmarks. Reproducible: Always Steps to Reproduce: 1. Add some bookmarks 2. Actively visit many pages from the above bookmarked sites 3. Clean your history by executing SQL queries against places.sqlite.moz_places table Actual Results: "Organize bookmarks" spills many errors and almost doesn't work. ASSERT: empty URL spec Stack Trace: o:PU__uri(null) 1:PTV_getCellText(10,[object TreeColumn]) Expected Results: Working bookmarks. Deleting history entries is NOT an option 'cause Firefox deletes entries one by one thus trashes your HDD. In the case I've presented I manually deleted around 7000 history entries based on their url. It's plain impossible to do that via history browser.
As a temporary workaround I've deleted the offending entries from the moz_bookmarks table.
Deleting history entries through the Firefox UI should become less painful once bug 402486 is fixed. I agree that executing what seem to be straightforward DELETEs against places.sqlite should not completely break the UI.
Component: Bookmarks → Places
QA Contact: bookmarks → places
I also propose that bookmarks urls have to be stored in a table other than moz_places.
In my eyes this is duplicate of bug 402486 if not invalid. You cannot expect any application to behave properly, if you corrupt its database integrity. If you would have deleted just moz_historyvisits (what does not break the integrity - see schema http://www.allpeers.com/sqlite/index.php?keyword=Places ), and then cleared the history, you would have desired effect in short time, because you would avoided iterations over visits one by one. If you look at nsNavHistoryExpire::ClearHistory, you will see, that there are cleanup functions called which delete places without visits or bookmarks, including orphaned favicons.
Oops, wrong bug referenced, this is duplicate to bug 409723.
The code should handle this type of problem gracefully. Clarifying the summary to reflect this.
Summary: Direct editing of places.sqlite history causes "Organize bookmarks" window to malfunction → Corrupt database record causes Places' "Library" window to malfunction
Severity: major → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Firefox 3.1
Version: unspecified → 3.0 Branch
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
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
We should not spend too much time trying to fix databases users have corrupted by their choice, running raw queries on a database is always the wrong thing to do. That said, PlacesMaintenance service already does this kind of cleanup once a week.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.