Bug 404146. Advancing through nsContainerFrame next-in-flows can make our InlineData->line invalid, so just null it out if it might have become invalid. r+sr=dbaron

This commit is contained in:
roc+@cs.cmu.edu 2008-01-09 19:18:44 -08:00
parent 92c8aaa72c
commit bf79c23ed9
2 changed files with 15 additions and 3 deletions

View File

@ -660,8 +660,10 @@ nsContainerFrame::DoInlineIntrinsicWidth(nsIRenderingContext *aRenderingContext,
styleBorder->GetBorderWidth(startSide) +
GetCoord(styleMargin->mMargin.Get(startSide, tmp), 0);
for (nsContainerFrame *nif = this; nif;
nif = (nsContainerFrame*) nif->GetNextInFlow()) {
const nsLineList_iterator* savedLine = aData->line;
nsContainerFrame* next;
for (nsContainerFrame *nif = this; nif; nif = next) {
for (nsIFrame *kid = nif->mFrames.FirstChild(); kid;
kid = kid->GetNextSibling()) {
if (aType == nsLayoutUtils::MIN_WIDTH)
@ -671,7 +673,16 @@ nsContainerFrame::DoInlineIntrinsicWidth(nsIRenderingContext *aRenderingContext,
kid->AddInlinePrefWidth(aRenderingContext,
static_cast<InlinePrefWidthData*>(aData));
}
next = (nsContainerFrame*) nif->GetNextInFlow();
if (next) {
// After we advance to our next-in-flow, the stored line may no
// longer be the correct line. Just forget it.
aData->line = nsnull;
}
}
aData->line = savedLine;
// This goes at the end no matter how things are broken and how
// messy the bidi situations are, since per CSS2.1 section 8.6

View File

@ -1146,7 +1146,8 @@ public:
, trailingWhitespace(0)
{}
// The line. This may be null if the inlines are not associated with a block.
// The line. This may be null if the inlines are not associated with
// a block or if we just don't know the line.
const nsLineList_iterator* line;
// The maximum intrinsic width for all previous lines.