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




Bookmarks & History
11 years ago
5 years ago


(Reporter: Artem S. Tashkinov, Unassigned)


3.0 Branch

Firefox Tracking Flags

(Not tracked)




11 years ago
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 "";

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:
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

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

Comment 2

11 years ago
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

Comment 3

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

Comment 4

10 years ago
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 ), 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

10 years ago
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
Priority: -- → P4
Severity: major → normal
Ever confirmed: true
Target Milestone: --- → Firefox 3.1
Version: unspecified → 3.0 Branch
Target Milestone: Firefox 3.1 → ---
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.

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.
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.