Closed
Bug 412243
Opened 17 years ago
Closed 16 years ago
Crash [@ nsContinuingTextFrame::GetFirstContinuation] with -moz-column, float
Categories
(Core :: Layout, defect, P3)
Core
Layout
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: jruderman, Assigned: MatsPalmgren_bugz)
References
Details
(Keywords: crash, testcase)
Crash Data
Attachments
(3 files, 1 obsolete file)
This fairly simple testcase makes Firefox crash [@ nsContinuingTextFrame::GetFirstContinuation]. The testcase is based on the crashtest for bug 391894.
Assignee | ||
Comment 1•17 years ago
|
||
Assignee: nobody → mats.palmgren
Status: NEW → ASSIGNED
Attachment #296924 -
Flags: superreview?(roc)
Attachment #296924 -
Flags: review?(roc)
Assignee | ||
Updated•17 years ago
|
Flags: blocking1.9?
OS: Mac OS X → All
Hardware: PC → All
Assignee | ||
Comment 2•17 years ago
|
||
Comment on attachment 296924 [details] [diff] [review] Patch rev. 1 Hmm, but why is a nsContinuingTextFrame the first continuation?
Attachment #296924 -
Flags: superreview?(roc)
Attachment #296924 -
Flags: review?(roc)
Assignee | ||
Updated•17 years ago
|
Group: security
Assignee | ||
Comment 3•17 years ago
|
||
This looks pretty bad actually... So, we're removing the DIV element and thus the SPAN. The SPAN has been split into 3 floats (in separate columns) and each float has a text frame. At the top is the content tree before removing the DIV. Then the frame tree at the start of nsCSSFrameConstructor::ContentRemoved(), the child frame to be destroyed is marked yellow (correct). I added an assertion in nsContinuingTextFrame::SetPrevInFlow() that asserts if 'aPrevInFlow' is null, that caught the stack for when the nsContinuingTextFrame became the first continuation. Then follows the frame tree when nsCSSFrameConstructor::ContentRemoved() returns, as you can see the error has already occurred here - we still have frames in the tree for the SPAN (magenta,lime) and for the text. The error occurs when we reflow the "b " text frame (brown) which is a nsContinuingTextFrame. The crash occurs because I used GetFirstContinuation() in the diagnostic code for bug 406380 (which apparently has never been used before?) http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/generic/nsTextFrameThebes.cpp&rev=3.160&root=/cvsroot&mark=5196#5169 I'm pretty sure the bug is in DeletingFrameSubtree(), like I was speculating in bug 411835, I think we must process next-in-flows for all descendant out-of-flows. I need to think about how to handle the placeholder continuations properly... which involves bug 404721 too. I'll try to come up with a combined patch on bug 411835.
Attachment #296924 -
Attachment is obsolete: true
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Priority: P2 → P3
Flags: wanted1.9.0.x+
Flags: blocking1.9-
Updated•16 years ago
|
Flags: tracking1.9+
Comment 4•16 years ago
|
||
Reporter | ||
Comment 5•16 years ago
|
||
With the first testcase, I see ###!!! ASSERTION: How can an nsContinuingTextFrame be the first continuation?: 'previous', file /Users/jruderman/trunk/mozilla/layout/generic/nsTextFrameThebes.cpp, line 3274 before the crash. Martijn's testcase2 doesn't crash for me.
Comment 6•16 years ago
|
||
Both testcases in comment #0 and comment #4 WFM on Mac trunk Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a2pre) Gecko/20080818150509 Minefield/3.1a2pre with mallocscribble. No assertions / crashes at all.
Comment 7•16 years ago
|
||
Jesse, can you confirm that this is WFM? Is it also true using Firefox 3.0 and, if so, do we have a fix range?
Reporter | ||
Comment 8•16 years ago
|
||
WFM on trunk (tested on Tiger). Yay!
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Updated•13 years ago
|
Crash Signature: [@ nsContinuingTextFrame::GetFirstContinuation]
Updated•9 years ago
|
Group: core-security → core-security-release
Updated•9 years ago
|
Group: core-security-release
Assignee | ||
Updated•9 years ago
|
Flags: in-testsuite?
You need to log in
before you can comment on or make changes to this bug.
Description
•