Closed Bug 14540 Opened 20 years ago Closed 20 years ago
[DOGFOOD] Crash mousing over bookmarks menu with large bookmarks file
I'm using a bookmarks.htm sizing ca. 250 KB. It seems to be cutted anywhere in the middle, since I only see a part of the largest submenu (4 or sometimes more submenus (of this submenu)) and no top level entries below the large submenu (on the same level of the submenu). Example: Submenu 1 Entry 2 Submenu 3 Submenu 4 Lots of entries Submenu 5 Lots of entries Submenu 6 Lots of entries Submenu 7 Some entries Missing entries Missing submenus Missing entries Missing submenus Missing entries This does not seem to be the "Enter twice" bug (can find it anymore).
ben: could you please attach your bookmarks.html (or bookmark.htm, on win32) to the bug report so i can reproduce this?
Waterson, I'd like to avoid this, this file is too personal. Try to generate a 250K file, please, it should occur with every large file. I'm sorry, that I'm unable to help you in this case.
can you try to deduce what is special about your bookmarks? or post a 250Kb bookmarks file that _isn't_ personal (e.g., machine generated) but illustrates the bug. as much as i'd like to help, i don't have time to chase every wild goose.
I hope, it's valid. Creation: shell script, imported and saved with comm 4.6.
ok, i'll take a look.
Could be a duplicate of Bug #13081, since Moz crashes now.
*** Bug 13081 has been marked as a duplicate of this bug. ***
Severity: normal → critical
OS: Linux → All
Summary: Large bookmarks.htm not displayed completely → Crash mousing over bookmarks menu with large bookmarks file
Changing summary & severity to reflect crash, and OS to all (also happens on Win98, apparent freeze on Mac). I have a much smaller file attached to dup Bug 13081 that also crashes.
Summary: Crash mousing over bookmarks menu with large bookmarks file → [DOGFOOD] Crash mousing over bookmarks menu with large bookmarks file
I don't think it is size alone. Don Melton is using a 1MB bookmarks file.
This is a PDT-, please provide more file to reproduce.
How many more files do you need? We have two files that reproduce this 100% Why do we need any more?
Component: RDF → ActiveX Wrapper
Target Milestone: M12 → M1
In an dogfood attempt, I deleted 2 folders withe by far the most bookmarks and voila - it works. Trudelle your "Windows" Folder is huge, too. Looks to me like huge single folders cause the crash (note: they don't need to be opened, they just have to exist).
Mozilla seems to have changed some fields to their first entries. Fixing.
Component: ActiveX Wrapper → RDF
Target Milestone: M1 → M12
It looks like there is only 1 bookmark in that folder. The rest are not in any folder. Maybe that is the problem.
Assignee: waterson → rjc
Status: ASSIGNED → NEW
Target Milestone: M12
rjc: can you take this one?
Up until recently, there was a hard-coded limit (set at 100) in boxes that Eric Vaughn recently fixed. (Sorry, don't recall the bug number.) Using a build from this morning, December 4, 1999: I tried Trudelle's bookmark file (attached to bug # 13081 and it works fine (if you ignore the asserts that mail/news fires due to seeing mailbox: URLs that it doesn't understand, since their format changed from 4.x to 5.0. [There's a bug on this problem, currently assigned to one of the mail/news guys.] I tried Ben's bookmarks file [attached to this bug] and it doesn't crash. Using the main menubar's Bookmark menu, its so big that the menu just seems to want to reflow forever trying to figure out how to lay out for display. Using the "Bookmark" menu on the personal toolbar, its slow but it does finally draw and work. Peter (Trudelle), I'm reassigning this back to you. I'm considering this to be a performance problem with menus/boxes/something with regards to XPToolkit stuff, so one of your guys should look at this from a performance viewpoint. Ben, if you get a chance, please try grabbing a current build and see if your private bookmark works any better (i.e. doesn't crash, but might not draw fast, if at all).
rfc, I just a have 2 very huge submenus now. Build from 12/02: No crash, it even works. However, while drawing, the upper half of the menu flashes for 2 min. or so. and blocks the complete UI (all of X). Mozilla seems to try to draw all of the menu on the screen, which of course fails. We have to figure out, how many items will fit on the screen and draw only them. As I see it, it's a menu bug. I don't need a fix before beta.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
No, we're not going to morph this bug into some other problem. If it doesn't crash then the box changes no doubt fixed it, as expected. Any problems after where it used to crash should be filed as a separate bug. resolving as fixed.
trudelle: lol. You're right. Filed bug #21019.
You need to log in before you can comment on or make changes to this bug.