780886 - "Data Manager" fails to "Forget This Data"; Domain reappears after "Forget About This Domain". Unable to delete.

Status: RESOLVED FIXED

(SeaMonkey :: Passwords & Permissions, defect)

Description

[Tom Sadlowski]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120715 Firefox/14.0.1 SeaMonkey/2.11
Build ID: 20120715041107

Steps to reproduce:

Open Data Manager.  Click on a domain name and press Delete; else right click on a domain name and select "Forget About This Domain".

Forget tab will appear displaying four options: Cookies, Permissions, Content Preferences, Passwords.

Selecting the "Content Preferences" box, then clicking "Forget This Data", removes the domain (provided it only has Content Preferences associated with it).

Close the Data Manager.  Open the Data Manager (re-start not necessary).  Domain will reappear.  Unable to remove domain or settings associated with it.



Expected results:

This issue has existed since the platform was transitioned to the Data Manager.  Now, the inability to remove domains has reached the point of annoyance.  Any way to manually remove?  Presume no longer possible as stored in a binary file.

Comment 1

[Phoenix]

Can't reproduce this on trunk, can you check, is problem exists for you on this build - http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-comm-central-trunk/seamonkey-2.14a1.en-US.win32.zip
?
Just unpack it to separate folder and run from there

Comment 2

[Tom Sadlowski]

DAMN!  That build tuned all my mail and bookmark files to 0kb.  Any idea how to recover more recent than backup?  My bad.

Problem still exists for me on the 2.14a1 build.

Only similar reports I could find were from this post:
https://groups.google.com/forum/?fromgroups#!topic/mozilla.support.seamonkey/N-he01Wv5LA

Also running two profiles, deleting one (and no did not delete the wrong profile).

Comment 3

[Phoenix]

That's is very unexpected result, I can't remember any introduced incompatibility from 2.2 times, so I'm suspecting that your profile folder was corrupted before.
Anyway, for bookmarks, go to bookmark manager, then Tools -> Restore, you can find bookmarks backups there. For mail I need more info, all files in <your profile>\Mail dir become zero sized? AFAIK, SeaMonkey (same as Thunderbird) doesn't do mail backups.
For main problem: as I understand, you was able to reproduce it on clean profile, right?

Comment 4

[Tom Sadlowski]

Bookmark backups dissappeared as well.  Needed to use Ontrack EasyRecovery in order to pull deleted bookmark files.  Mail was not so lucky; all my mail files became zero-sized.  Merging what I was able to recover with my prior backup.  Damn me for not copying my profile for testing like I always do!

I rebuilt my profile after the transition, will do again and see if the problem is resolved.  Personally, that mail/bookmark issue with 2.14a is a far greater problem!

Comment 5

[therube]

Confirmed.

It appears that it is not always, fully, deleting Data.

Pick a domain with multiple cookies & multiple permissions.
mozilla.net or mozilla.org might be a good ones, likely to have both cookies & permissions.

Note the number of each that exist, 3 cookies & 2 permissions, in my case.

Delete on the domain, selecting both Cookies & Permissions, then Forget.
mozilla.org "disappears".

Refresh the page (about:data).

mozilla.org has returned from the dead, now with one cookie & no permissions.

Repeat the deletion.
This time the data is gone.

If you have a domain with more cookies, permissions, it may well take more then two Forgets before it is forgotten.

Or load www.yahoo.com.
That looks to give you 9 cookies right off the bat.

Click delete on the domain, Cookies, Forget.
Refresh.
4 cookies remain.
Repeat.
2 cookies remain.
Repeat.
1 cookie remains.
Repeat.

It is finally gone.

Note that if instead of Forgetting, if you were to highlight all of the cookies (rather then the Domain), & Delete, then they are actually gone (& the Domain goes too, assuming no other Data categories existing for yahoo.com).

I'll go out on a limb & say at any time where more then one data item exists in a particular category, it will take more then one Forget before a domain is completely forgotten.  So two cookies means at least two Forget's.  (Ah, forget that, because that test just failed.)

Clear Private Data (Cookies) does look to do so fully.

An aside.  You may want to put the browser in offline mode during your tests, as sites like youtube are likely to "refresh" (Flash ads or whatever), regenerating cookies.  (Interesting.  Even offline, when I manually "refreshed" yahoo.com, it regenerated a cookie.)

It might only be when (multiple) cookies (for a domain) are involved where this bug manifests?  As with no existing cookies, then adding 3 Permissions to yahoo.com, then Forgetting, yahoo.com was deleted fully from the first Forget.

Comment 6

[Tom Sadlowski]

Built new profile in SeaMonkey 2.11.  Initially no problems with the ability to modify settings in the Data Manager.  Now, unable to remove domain or modify settings associated with it, as prior.  Do not want to rebuild profile again -- too time consuming.

Why is profile becoming corrupted?  And once becoming corrupted why is it unable to modify the entries in the Data Manager?

Is there anyway to prevent additions to Data Manager 'Preferences' in about:config?  Automatically add for sites that I will only visit once.  Sort of a security concern (from a logging standpoint).

Comment 7

[Tom Sadlowski]

Able to work-around by manually editing "content-prefs.sqlite".  Records in the database failed to reveal what situation is preventing record removal.

Comment 8

[Phil]

(In reply to Tom Sadlowski from comment #7)
> Able to work-around by manually editing "content-prefs.sqlite".  Records in
> the database failed to reveal what situation is preventing record removal.

Seems this is still a bug in 2.15.2.

I have tried finding entries to delete in "content-prefs.sqlite" (I want to remove domains) but could not see them... what table/column do I need to look at?

Comment 9

[Tom Sadlowski]

Still an active bug.

Appears on these newer SeaMonkey versions, that the data fails to show in the tables.  Rather than editing, I now resolve by merely replacing the "content-prefs.sqlite" file with one that was created after configuration.  For you, I would recommend creating a new profile, and copy that "content-prefs.sqlite" file to replace your corrupt "content-prefs.sqlite" file in your active profile.  Be sure to rename your present file, to allow for the possibility of rolling back, should difficulties arise.

Have yet to see any data of value stored in that "content-prefs.sqlite" file.

Comment 10

[Robert Kaiser]

Bah, I think I know what's up here. I guess the numbers are always more or less cut in half?

It's just a bad idea to loop forward through numeric indexes of an array to remove them. I haven't tested it yet, but I have a patch against the add-on - I hope I can apply that to the suite code as well.

Comment 11

[Robert Kaiser]

Attachment: patch: do all index-based removals in forget functions in backwards order

OK, this patch makes all array-index-based removals inside forget functions be done in reverse order (and copies a comment from one such existing case to all the those places so it's clear why we do things backwards there.

This is a rather obvious bug once you look at it (and it's all my fault) so I hope this is the cause for this bug.

Comment 12

[Ian Neal]

Comment on attachment 712317 [details] [diff] [review]
patch: do all index-based removals in forget functions in backwards order

Would it be better to use --i rather than i--? I believe you can then just use "foo.length" rather than "foo.length - 1"
Either way (if the second way works) r=me

Comment 13

[Robert Kaiser]

(In reply to Ian Neal from comment #12)
> Comment on attachment 712317 [details] [diff] [review]
> patch: do all index-based removals in forget functions in backwards order
> 
> Would it be better to use --i rather than i--? I believe you can then just
> use "foo.length" rather than "foo.length - 1"
> Either way (if the second way works) r=me

I tried the solution with "foo.length" and "--i" but we still enter the loop with foo.length in that case, so we still need to use "foo.length - 1".

Because of that, I'm landing the original patch, I hope that's OK.

Comment 14

[Robert Kaiser]

http://hg.mozilla.org/comm-central/rev/aba7902de634