Closed
Bug 550306
Opened 14 years ago
Closed 3 years ago
Too-much-recursion crash with <xul:listbox>, negative margin
Categories
(Core :: XUL, defect)
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)
Comment 1•14 years ago
|
||
So what makes listboxes set up a post-reflow callback?
Comment 2•14 years ago
|
||
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.
Comment 3•14 years ago
|
||
I wonder whether a zero row height could be the problem.
Reporter | ||
Comment 4•14 years ago
|
||
Due to the combination of this bug with bug 507876, I can't look for other too-much-recursion crashes while fuzzing.
Reporter | ||
Comment 5•14 years ago
|
||
Bug 575446 shows a similar too-much-recursion pattern with xul trees.
Reporter | ||
Comment 6•14 years ago
|
||
Reporter | ||
Comment 7•14 years ago
|
||
This makes fuzzing difficult.
blocking2.0: --- → ?
OS: Mac OS X → Windows 7
Comment 8•14 years ago
|
||
*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: ? → -
Reporter | ||
Comment 9•14 years ago
|
||
After re-reading comment 2, I'm moving "testcase 2" along with "this makes fuzzing difficult" to bug 601999.
Reporter | ||
Updated•14 years ago
|
Attachment #478958 -
Attachment is obsolete: true
Comment 10•3 years ago
|
||
Hey Jesse,
Can you still reproduce this issue or can it be closed?
Flags: needinfo?(jruderman)
Comment 11•3 years ago
|
||
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.
Description
•