Closed
Bug 542136
Opened 16 years ago
Closed 16 years ago
"ASSERTION: Incorrect aState.mPrevChild before inserting line at end"
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.9.3a1
People
(Reporter: jruderman, Assigned: tnikkel)
References
Details
(Keywords: assertion, testcase, verified1.9.2, Whiteboard: [sg:critical?])
Attachments
(2 files)
402 bytes,
text/html
|
Details | |
1.25 KB,
patch
|
roc
:
review+
beltzner
:
approval1.9.2.2+
beltzner
:
approval1.9.1.9+
|
Details | Diff | Splinter Review |
###!!! ASSERTION: Incorrect aState.mPrevChild before inserting line at end: 'aState.mPrevChild == mFrames.LastChild()', file /Users/jruderman/mozilla-central/layout/generic/nsBlockFrame.cpp, line 2162
bz marked a previous bug with this assertion as security-sensitive (bug 522170), so I'm filing this one as security-sensitive.
Reporter | ||
Updated•16 years ago
|
Group: core-security
Assignee | ||
Comment 1•16 years ago
|
||
On trunk this assertion shouldn't itself lead to a security problem. On 3.6 and earlier it is likely to cause a messed up frame tree, so a security problem is likely just around the corner.
Assignee | ||
Comment 2•16 years ago
|
||
So I think the problem lies with this bit of code in nsBlockFrame::ReflowInlineFrame http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsBlockFrame.cpp#3838
// If we just ended a first-letter frame or reflowed a placeholder then
// don't split the line and don't stop the line reflow...
if (!(frameReflowStatus & NS_INLINE_BREAK_FIRST_LETTER_COMPLETE) &&
nsGkAtoms::placeholderFrame != frameType) {
// Split line after the current frame
*aLineReflowStatus = LINE_REFLOW_STOP;
rv = SplitLine(aState, aLineLayout, aLine, aFrame->GetNextSibling(), aLineReflowStatus);
NS_ENSURE_SUCCESS(rv, rv);
}
At this point *aLineReflowStatus is already LINE_REFLOW_STOP because the reflow status was break after for the frame we just reflowed, but we don't split the line because of the first letter complete check. And so we stop reflow after 1 of 2 frames on the line and when we get back to nsBlockFrame::ReflowDirtyLines mPrevChild is not the last frame on the line. Adding "|| *aLineReflowStatus == LINE_REFLOW_STOP" to the if condition fixes the asserts for me.
Sounds right.
Assignee | ||
Comment 4•16 years ago
|
||
Assignee: nobody → tnikkel
Attachment #423615 -
Flags: review?(roc)
Attachment #423615 -
Flags: review?(roc) → review+
Assignee | ||
Comment 5•16 years ago
|
||
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
Assignee | ||
Comment 6•16 years ago
|
||
After some bake time on trunk this is something that would probably be good to have on the branches.
blocking1.9.1: --- → ?
blocking1.9.2: --- → ?
Updated•15 years ago
|
blocking1.9.1: ? → needed
blocking1.9.2: ? → needed
Updated•15 years ago
|
Assignee | ||
Updated•15 years ago
|
Attachment #423615 -
Flags: approval1.9.2.2?
Attachment #423615 -
Flags: approval1.9.1.9?
Comment 7•15 years ago
|
||
Comment on attachment 423615 [details] [diff] [review]
patch
a=beltzner for 1.9.2.2 and 1.9.1.9
Attachment #423615 -
Flags: approval1.9.2.2?
Attachment #423615 -
Flags: approval1.9.2.2+
Attachment #423615 -
Flags: approval1.9.1.9?
Attachment #423615 -
Flags: approval1.9.1.9+
Assignee | ||
Comment 8•15 years ago
|
||
Assignee | ||
Comment 9•15 years ago
|
||
Comment 10•15 years ago
|
||
I notice with the testcase post-fix that I'm not seeing the assert above anymore on OS X but I do get:
###!!! ASSERTION: overflow list w/o frames: 'mFrames.NotEmpty()', file /Users/albill/mozilla-192/layout/generic/nsInlineFrame.cpp, line 374
Is this a non-issue?
Assignee | ||
Comment 11•15 years ago
|
||
I don't get that assertion on trunk, I would guess because of bug 533379 which is fixed on trunk but not 1.9.2.
Comment 12•15 years ago
|
||
Well, that isn't *this* assertion so I will call this verified1.9.2.
Keywords: verified1.9.2
Comment 13•15 years ago
|
||
verified 1.9.2-2 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.2) Gecko/20100321 Firefox/3.6.2 ID:20100321170417 (debug build) - the testcase didn't caused the assertion from comment #0 - for comment 10 i have made a comment in bug 533379 - maybe that bug need to land on 1.9.2 too
Updated•15 years ago
|
Flags: wanted1.9.0.x-
Updated•15 years ago
|
Group: core-security
Assignee | ||
Comment 14•15 years ago
|
||
Added crashtest
http://hg.mozilla.org/mozilla-central/rev/f8c56496ae7d
Flags: in-testsuite? → in-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•