Closed Bug 550306 Opened 14 years ago Closed 3 years ago

Too-much-recursion crash with <xul:listbox>, negative margin

Categories

(Core :: XUL, defect)

x86
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED INCOMPLETE
Tracking Status
blocking2.0 --- -

People

(Reporter: jruderman, Unassigned, NeedInfo)

References

Details

(Keywords: crash, testcase, Whiteboard: [sg:dos])

Attachments

(1 file, 1 obsolete file)

142 bytes, application/vnd.mozilla.xul+xml
Details
The repeating part of the stack:

169 PresShell::FlushPendingNotifications(mozFlushType) + 706 (nsPresShell.cpp:4800)
170 PresShell::HandlePostedReflowCallbacks(int) + 250 (nsPresShell.cpp:4692)
171 PresShell::DidDoReflow(int) + 40 (nsPresShell.cpp:7215)
172 PresShell::ProcessReflowCommands(int) + 419 (nsPresShell.cpp:7479)
173 PresShell::FlushPendingNotifications(mozFlushType) + 706 (nsPresShell.cpp:4800)
So what makes listboxes set up a post-reflow callback?
Well, it seems to work like this: During reflow, when a row is discovered to be taller than any row seen so far, all the rows are resized to the same size, and the listbox's minheight is also increased if its height was based on the number of rows. A reflow callback is then posted to update the layout. Note that resizing the rows will change the first visible item (e.g. if item 12 was the first visible, and the row height increased from 20 to 24, then item 10 will now appear to be the first visible), so the callback posts another callback to change the scroll position so that the originally first visible row is correct.
I wonder whether a zero row height could be the problem.
Due to the combination of this bug with bug 507876, I can't look for other too-much-recursion crashes while fuzzing.
Bug 575446 shows a similar too-much-recursion pattern with xul trees.
Attached file testcase 2 (obsolete) —
This makes fuzzing difficult.
blocking2.0: --- → ?
OS: Mac OS X → Windows 7
*This* bug about XUL is not a blocker because it can't be touched by content. Jesse will file a different bug about filter:, and that will probably be a blocker.
blocking2.0: ? → -
After re-reading comment 2, I'm moving "testcase 2" along with "this makes fuzzing difficult" to bug 601999.
Attachment #478958 - Attachment is obsolete: true
Depends on: 1403656

Hey Jesse,
Can you still reproduce this issue or can it be closed?

Flags: needinfo?(jruderman)

Marking this as Resolved > Incomplete due to the lack of info.
If anyone is able to reproduce this issue re-open it or file a new bug.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: