421189 - URIProperties/POSTData annotations have not been removed correctly, so pages are not deleted from places history

Status: RESOLVED WORKSFORME

(Firefox :: Bookmarks & History, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b5pre) Gecko/2008030504 Minefield/3.0b5pre ID:2008030504

If you delete a bookmark which is also a history entry it doesn't get deleted from the moz_places table after you clear the history.

Steps to reproduce:
1. Goto http://www.google.de and bookmark this page
2. Clear the history
3. Goto http://www.heise.de and bookmark this page
4. Open history menu to be sure only heise.de is listed
5. Open the Library and delete both bookmarks
6. Restart Firefox
7. Clear the history
8. Restart Firefox
7. Open places.sqlite 

Now both websites aren't shown within the Library and the history menu. But if you open the table moz_places you can still see the entry for heise.de. This entry will not be deleted until you bookmark this website again and remove it immediately.

This is still a privacy issue. Asking for blocking-firefox3.

Comment 1

[Ed Lee :Mardak]

I can't reproduce this. Clearing the history will remove all entries from moz_places unless it's bookmarked, and you said to remove the bookmark. Are you sure it isn't loading the page after restarting?

Comment 2

[Mike Connor [:mconnor]]

Need confirmation before we block on this...

Comment 3

[Marco Bonardo [:mak]]

moz_places entries are mantained if they are bookmarked (have an entry in moz_bookmarks) or they have a page annotation (have an entry in moz_annos with expiration = 4). clearly when you find the entry in moz_places you should check that you don't have any visit in moz_historyvists and don't have one of the upper.

Comment 4

[Marco Bonardo [:mak]]

i've tried your STRs, but cannot reproduce

Comment 5

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008030600 Minefield/3.0b5pre ID:2008030600

I have also tried the STR and cannot reproduce.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I run a test again some minutes ago and I'm also not able to reproduce. Give me some time please to get a testcase or a working STR.

(In reply to comment #3)
> moz_places entries are mantained if they are bookmarked (have an entry in
> moz_bookmarks) or they have a page annotation (have an entry in moz_annos with
> expiration = 4). clearly when you find the entry in moz_places you should 

What makes places entry special if they have an entry in moz_annos with expiration=4?

Comment 7

[Marco Bonardo [:mak]]

expiration = 4 is EXPIRE_NEVER so that annotation cannot be removed, so the page cannot be removed. Are usually used to mark items that should not be deletable or have special meanings

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Resetting severity to normal until it's clear what happens in my case.

Thanks Marco, but I'm still not able to identify why this entry, which doesn't get deleted from my places.sqlite, is so special. I'll attach this file so you could have a look at it. It's the places entry with id 667. And no idea if my database file was corrupted while doing a regression test back to March last year. It would be nice if you could have a look at it.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: places.sqlite with broken entry

Comment 10

[Marco Bonardo [:mak]]

that entry has a URIProperties/POSTData annotation with expire_never... no that anno should not be there.

LXR tell me that we are using that anno here

http://lxr.mozilla.org/seamonkey/source/browser/base/content/browser-places.js#975

and this comments tells the remaining part
// bug 398914 - move all post-data annotations from URIs to bookmarks

for some reason in your profile that migration has not happened correctly, try setting the pref browser.places.migratePostDataAnnotations to true

Comment 11

[Marco Bonardo [:mak]]

ops, i asked blocking but didn't want

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #10)
> for some reason in your profile that migration has not happened correctly, try
> setting the pref browser.places.migratePostDataAnnotations to true

Yes, that does the trick. Now the suspicious entry was removed from the database. 

Comment 13

[Marco Bonardo [:mak]]

this should be actually somehow WFM, EXPIRE_NEVER now works fine and does not block the removal of items, it simply tell us to retain the anno till the url is present in the database.

Comment 14

[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