Closed Bug 14540 Opened 20 years ago Closed 20 years ago

[DOGFOOD] Crash mousing over bookmarks menu with large bookmarks file

Categories

(Core Graveyard :: RDF, defect, P3, critical)

x86
All
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: BenB, Assigned: trudelle)

References

Details

(Whiteboard: [PDT-])

Attachments

(1 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.
Attached file Sample bookmarks.html
I hope, it's valid. Creation: shell script, imported and saved with comm 4.6.
Status: NEW → ASSIGNED
Target Milestone: M12
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.
Whiteboard: [PDT-]
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?
Assignee: rjc → trudelle
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.
Status: RESOLVED → VERIFIED
trudelle: lol. You're right. Filed bug #21019.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.