404171 - Corrupt database record causes Places' "Library" window to malfunction

Status: RESOLVED WONTFIX

(Firefox :: Bookmarks & History, defect, P4)

Description

[Artem S. Tashkinov]

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.

Comment 1

[Artem S. Tashkinov]

As a temporary workaround I've deleted the offending entries from the moz_bookmarks table.

Comment 2

[Jesse Ruderman]

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.

Comment 3

[Artem S. Tashkinov]

I also propose that bookmarks urls have to be stored in a table other than moz_places.

Comment 4

[Ondrej Brablc]

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.

Comment 5

[Ondrej Brablc]

Oops, wrong bug referenced, this is duplicate to bug 409723.

Comment 6

[Dietrich Ayala (:dietrich)]

The code should handle this type of problem gracefully. Clarifying the summary to reflect this.

Comment 7

[Gervase Markham [:gerv]]

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

Comment 8

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

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.