Bommels05/Mozilla
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Bug 259032. DeCOMtaminate nsIFrame::GetNext/PrevInFlow. r+sr=roc, patch by Will Levine

Browse Source 
git-svn-id: svn://10.0.0.236/trunk@162269 18797224-902f-48f8-a5cc-f745e15eee43
This commit is contained in:
roc+%cs.cmu.edu
2004-09-14 02:28:03 +00:00
parent 97d5ac0507
commit ab88d1e1ac
67 changed files with 291 additions and 584 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
mozilla/layout/generic/nsInlineFrame.cpp
View File

@@ -261,8 +261,7 @@ nsInlineFrame::RemoveFrame(nsPresContext* aPresContext,
// When the parent is an inline frame we have a simple task - just
// remove the frame from its parents list and generate a reflow
// command.
nsIFrame* oldFrameNextInFlow;
aOldFrame->GetNextInFlow(&oldFrameNextInFlow);
nsIFrame* oldFrameNextInFlow = aOldFrame->GetNextInFlow();
parent->mFrames.DestroyFrame(aPresContext, aOldFrame);
aOldFrame = oldFrameNextInFlow;
if (aOldFrame) {
@@ -514,8 +513,7 @@ nsInlineFrame::ReflowFrames(nsPresContext* aPresContext,
// its parent frame pointer, too. Otherwise, if we reflow frame and it's
// complete we'll fail when deleting its next-in-flow which is no longer
// needed. This scenario doesn't happen often, but it can happen
nsIFrame* nextInFlow;
frame->GetNextInFlow(&nextInFlow);
nsIFrame* nextInFlow = frame->GetNextInFlow();
while (nextInFlow) {
// Since we only do lazy setting of parent pointers for the frame's
// initial reflow, this frame can't have a next-in-flow. That means
@@ -523,7 +521,7 @@ nsInlineFrame::ReflowFrames(nsPresContext* aPresContext,
// not, then something is wrong
NS_ASSERTION(mFrames.ContainsFrame(nextInFlow), "unexpected flow");
nextInFlow->SetParent(this);
nextInFlow->GetNextInFlow(&nextInFlow);
nextInFlow = nextInFlow->GetNextInFlow();
}
}
rv = ReflowInlineFrame(aPresContext, aReflowState, irs, frame, aStatus);