From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc1) Gecko/20020413 BuildID: 2002041308-GMAKE I'd noticed that when I click on the Bookmarks menu the list was really slow to come up. At first, from searching Bugzilla, I thought this was deue to IE Favourites, but I don't have that folder. Then I noticed that I had two Personal Toolbar Folder's. I guess I got this when I imported bookmarks from my old Netscape 4.x list. After I deleted the dup Toolbar folder, performance is perfect. I'm not sure if this is due to a dup Toolbar folder, or just the fact that I had a dup folder. I guess one shouldn't be able to create a dup folder, and the import feature should do something to prevent dup folders from being created. Reproducible: Always Steps to Reproduce: 1. Have existing Bookmarks with a Personal Toolbar Folder 2. Import bookmarks from N4.x that also has a Personal Toolbar folder 3. Click on the Bookmarks Menu. Actual Results: List is slow to come up. Expected Results: Fast representation of the bookmark list. I'm designating this Major as it has the potential to manifest itself with v1.0.0 of Mozilla, which would be a bad thing.

Not major, since no loss of function. Adding perf keyword

Oh well, if slow performance is "normal", then I guess the IE vs Netscape/Mozilla competition has already been won. Just think, if Mozilla took 10 minutes to start up, it would be marked as "normal" as it isn't a loss of functionality.

On second thought, this probably isn't a bug either. Changing severity to Enhancement.

David, this is not a request for enhancement, it is a performance bug. Resetting severity to normal. I don't think this is major for two reasons: 1- You're the only person to have encountered this bug. If this were a more wide-spread problem, the severity would be increased. 2- The bookmark menu still functions (albeit slowly). Users can still do everything they expect to be able to do. To help track down your bug, could you provide us with the bookmark file you were using that slowed down your system? It would help developers narrow down the problem and hopefully get a fix out quicker. Thanks

No, I can't provide the bookmark file because, as I said in the original report, I deleted the dup entry. I also described in the "Steps to Reproduce" how one could get a similar book mark file as I had. If this process isn't working, please let me know and I'll see what I can do to duplicate the problem.

I have also noticed this (build 2001051006 win NT) but the slowdown appears to be related to the number of items in the bookmark file. I "cleaned up" my bookmarks file to report another bug (see Bug 145055 for the bookmarks file) and although this file has 4 "personal toolbar folder" entries, this "cleaned" version is faster than the "original" file. (I cleaned the file to remove links related to work, links that contain IDs and or passwords, etc -- stuff I don't want to share with the world) The first time I tried to look at my Bookmarks (with the original, 318,092 byte unedited file, as created by importing my netscape4 settings) it took so long to bring up the contents that I gave up -- the Bookmarks window was there but there was little "content" in it You may be able to re-create the problem by gathering bookmark files from a few different people and importing them -- not all of my files that I imported were for the same user and one of them was from whatever version of netscape was out in 1998. There was one import "session" where I imported two files, one after the other (I though Netscape would magically merge them, but it did not), and I at another time I imported another file -- I do not remember the order (whether I added the two files and then one, or first added one, and then did the two at a later date) I did some editing of the bookmarks in between the two import "sessions"

Reporter, can you reproduce this problem in Mozilla 1.0?

Do you mean "1.0", "1.1a", or any TRUNK build after 1.0 was branched?

Any of the above.

After further research, and the fact that my bookmarks are slow anyway (see Bug #62907) I don't think I can provide any meaningful tests.

I'm marking this bug as WORKSFORME until you can provide a consistant way to reproduce it.