Closed Bug 506208 Opened 15 years ago Closed 14 years ago

IE bookmarks still listed in searches for bookmarks after deleting Imported IE Favorites folder or changing its ID

Categories

(SeaMonkey :: Bookmarks & History, defect)

x86
Windows Vista
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: my_spam_basket, Unassigned)

References

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.1pre) Gecko/20090717 SeaMonkey/2.0b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.1pre) Gecko/20090717 SeaMonkey/2.0b1

Bookmarks imported from Internet Explorer (maybe from other supported browser too) on first launch after Seamonkey installation or deletion of default profile are still shown in SM searches for bookmarks both in sidebar and Bookmarks manager.

Reproducible: Always

Steps to Reproduce:
1. delete previous default profile folder or make a completely new SM installation; 
2. SM automatically imports IE bookmarks; 
3. delete *all* bookmarks and close SM;
4. re-open SM and search your bookmarks for a word you are sure was in them.
Actual Results:  
Entries of deleted bookmarks are still listed in searches for bookmarks.

Expected Results:  
No entry should be listed in searches because there is *no* *actual* bookmark.

I have seen this behavior even when I bookmark a website in SM and the delete it. In the bookmarks manager is not listed anymore, but it's still there in searches.
Just an image of SM UI showing this bug
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
V.Duplicate
Status: RESOLVED → VERIFIED
Version: unspecified → Trunk
Oh, 2nd thought:

(In reply to comment #0)
> Bookmarks imported from Internet Explorer (maybe from other supported browser
> too) on first launch after Seamonkey installation or deletion of default
> profile are still shown in SM searches for bookmarks both in sidebar and
> Bookmarks manager.
> 
> 3. delete *all* bookmarks and close SM;
> 4. re-open SM and search your bookmarks for a word you are sure was in them.

luctur, then when do the deleted bookmarks go away from search? On 2nd close+reopen? Never?

(In reply to comment #2)
> *** This bug has been marked as a duplicate of bug 123679 ***

Jens, did you actually reproduced and verified that your patch in bug 123679 fixes this?
(In reply to comment #4)
> (In reply to comment #2)
> > *** This bug has been marked as a duplicate of bug 123679 ***
> 
> Jens, did you actually reproduced and verified that your patch in bug 123679
> fixes this?

My patch makes sure that deleted bookmarks do not show up in searches. Deleting all bookmarks is just a special case of deleting a few so that doesn't make a difference.

However bookmarks are always deleted for good for me if I completely shut down and reopen SeaMonkey. luctur, do you really completely shut down SM in between steps 3 and 4? Like File/Exit? No seamonkey.exe in the Task Manager Processes list?

AFAIK there is no cache for bookmarks so on restart there should be no difference between the normal bookmarks view and the filtered one (search). So even if the bookmarks file was not writable (no permissions or another application has it open) the normal bookmarks view and the filtered one should match initially.

Anyway, if luctur can really reproduce this cross-session he should first try the patch from bug 123679 first (I can provide a patched bookmarks.js and instructions how to install it) before resetting the status of this bug.
I can reproduce the bug across sessions.

Right now I've a clean system, so if you can provide a patched bookmarks.js file and related instructions (if any), I can try again once more time from scratch.

For direct contact, use the email addreess I use here.
I add here what I've already said to Jens in private mail:

I've done some tests with this patched bookmarks.js.

SM was on a clean install, so it has imported IE bookmarks.

I've deleted some bookmarks, closed SM, waited a couple of minutes and then re-opened it.

Well, the bookmarks are gone, but their search entries are still there both in the search tab of the sidebar and in the Bookmarks Manager.

Here, what I've used: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.3pre) Gecko/20090731 SeaMonkey/2.0b2pre
More tests:

a) the modified bookmarks.js works with new SM bookmarks;
b) the modified bookmarks.js *doesn't* work with imported IE bookmarks.

Please pay attention that I've moved the imported bookmarks from SM "IE" bookmark folders to the top level "Bookmarks" in the Bookmarks manages.

Now, I'll try to eradicate the automatically imported bookmarks and go on with even more tests.
Can you reproduce with Firefox current v3.5.3pre?
Firstly, about Seamonkey: I can confirm that the issue is with imported bookmarks.

a) I've manually deleted the bookmarks.html file in my profile folder. At next launch, SM has populated my bookmarks with Mozilla community links *only*. I've deleted them, closed and re-opened SM. There was no track of the deleted bookmarks in sidebar or Bookmarks manager searches. Same thing if I bookmark a new site from the web;

b) I've manually deleted the whole profile folder. At next launch, SM has populated my bookmarks with IE imported bookmarks too. If I delete them and then close and reopen SM, I can still see the search entries. If I move them from "IE imported bookmarks" folder to the top level "Bookmarks", I can see double search entries;

c) I've exported my bookmarks from IE 8, Opera 10 beta and Firefox 3.5.1 in a plain "bookmarks.html" file. Then, I've imported each one into SM via Bookmarks Manager Importing tool. They were imported into top level "Bookmarks" and If I deleted one, closed and reopened SM, I could still see the search entries. Again, pay attention that I've manually deleted my profile folder after every importation.

Then, about Firefox: I'm downloading it, but I don't know if I've enough time to test it this week-end
OK, I've tested latest FF 3.5.3pre and there's no problem at all with deleted bookmarks' searches neither with newly created ones nor with those I've imported.
Dumb question: if I see deleted bookmarks across sessions, but they are not in my SM "bookmarks.html" file inside my profile, where they can be? What file can record those search entries?

I've even opened places.sqlite with SQLiteSpy, and the bookmarks tables are there, but they are not populated, so it's true that SM still doesn't use Places for bookmarks, like it was told me in the seamonkey dev newsgroup. (OK, I shouldn't have checked that, after having had those replies in the NG, but you know...)
OK, sorry for the confusion. This is probably a different issue than bug 123679. For now I'll change this back to UNCONFIRMED (I'm not sure I see exactly the same as you do yet so I cannot set it to NEW yet). I also added "imported" to the summary.

I have two questions:
1. I can reproduce this (with and without my patch from bug 123679) when I delete the whole Imported IE Favorites folder (deleting all bookmarks obviously includes this case) but not when deleting only individual bookmarks or subfolders from below Imported IE Favorites. Does it happen for you in both cases or like I said?
2. Can you please check if bug 96789 describes the same problem you are seeing? If yes I'd mark this bug as a dupe of that and continue discussion there (it's older and has more people on CC).(In reply to comment #12)

> Dumb question: if I see deleted bookmarks across sessions, but they are not in
> my SM "bookmarks.html" file inside my profile, where they can be? What file can
> record those search entries?

That's simple: the original IE favorite. Just rename a part of the name of one and search for the old and new parts.

I was also surprised to see that. My guess is that once the Imported IE Favorites folder has been deleted SM falls back to reading the original favorites.
Status: VERIFIED → UNCONFIRMED
Resolution: DUPLICATE → ---
Summary: Deleted bookmarks are still listed in searches for bookmarks → Deleted imported bookmarks are still listed in searches for bookmarks
(In reply to comment #13)

[...]

> I have two questions:
> 1. I can reproduce this (with and without my patch from bug 123679) when I
> delete the whole Imported IE Favorites folder (deleting all bookmarks obviously
> includes this case) but not when deleting only individual bookmarks or
> subfolders from below Imported IE Favorites. Does it happen for you in both
> cases or like I said?

You're right, I can see it only if I delete or move *all* Imported IE Favorites.

In fact, I usually move them during first SM launch, just after importation.

> 2. Can you please check if bug 96789 describes the same problem you are seeing?
> If yes I'd mark this bug as a dupe of that and continue discussion there (it's
> older and has more people on CC).(In reply to comment #12)

Maybe, but see my comment below.

> > Dumb question: if I see deleted bookmarks across sessions, but they are not in
> > my SM "bookmarks.html" file inside my profile, where they can be? What file can
> > record those search entries?
> 
> That's simple: the original IE favorite. Just rename a part of the name of one
> and search for the old and new parts.
> 
> I was also surprised to see that. My guess is that once the Imported IE
> Favorites folder has been deleted SM falls back to reading the original
> favorites.

You're right twice! SM falls back to IE favorites when you have no "bookmarks.html" or other imported bookmarks.

Here how I got the evidence:

1) import IE bookmarks;
2) close SM;
3) change one IE bookmark by adding the string "CHANGED" to its name;
4) delete SM "bookmarks.html" in your profile folder or delete all your imported bookmarks;
5) reopen SM and search your bookmarks for the word "CHANGED", you should see that bookmark though it was not added during first importation. I see it.

SM falls back to the content of IE Favorites folder even when I move all my imported bookmarks from the original location to top level inside SM Bookmarks Manager. You can test it with the same procedure shown above.

That's completely nonsense, because in my case, my default browser before installing SM was Firefox!

I suppose SM code is showing its age here since it assumes IE is the only other browser available on (Windows) user's system. Just a bad and confusing behavior.

Likely, this is what other users (in bug 96789 too) and I are seeing. The fall back when there are no other bookmarks available is acceptable, though users may not want such behavior if they have FF, Opera, Safari etc, but the fall back when you move your imported favorites is misleading and, IMO, definitely a bug.
Now that I we can both reproduce the same I'm marking this NEW and changing the subject to what this really is about: The problem only occurs when deleting the Imported IE Favorites folder or changing its ID in bookmarks.html from "NC:SystemBookmarksStaticRoot" to something else.

Since changing the ID is all it takes to trigger this bug I suppose the problem is in nsBookmarksService.cpp which contains the code that checks that value, probably HandleSystemBookmarks() which seems to "import" when the folder does not exist. I'm not an expert in that field, though. Someone with a little more understanding of that code needs to verify that and hopefully come up with a fix. Anyone?

I also changed my mind about bug 96789. It's older and has more CCs but doesn't contain much information. Thus I'll mark it as a dupe of this one.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Deleted imported bookmarks are still listed in searches for bookmarks → IE bookmarks still listed in searches for bookmarks after deleting Imported IE Favorites folder or changing its ID
Trunk (and 2.1a3) is now using Places as the bookmarks back-end, which doesn't support the special handling of IE Favorites anymore (only migration and point-in-time importing). Thus this bug has been become invalid. I still checked that deleting the Imported IE Favorites folder which is migrated from the old bookmarks.html file does in fact result in no matches when searching for formerly present IE bookmarks, though.
Status: NEW → RESOLVED
Closed: 15 years ago14 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: