roytam1/UXP
1
0
Fork 0
mirror of https://github.com/roytam1/UXP.git synced 2026-05-26 13:58:49 +00:00
Code Issues Projects Releases Wiki Activity

Bug 1415843 - Remove an unneeded call to AdjustAppendParentForAfterContent

Browse Source 
Tag #1375
This commit is contained in:
Matt A. Tobin
2020-04-17 07:22:26 -04:00
committed by Roy Tam
parent b67dd1398d
commit 5cef146d97
1 changed files with 0 additions and 46 deletions
Download Patch File Download Diff File Expand all files Collapse all files
layout/base/nsCSSFrameConstructor.cpp
-46
View File
@@ -7875,8 +7875,6 @@ nsCSSFrameConstructor::ContentRangeInserted(nsIContent* aContainer,
return;
}
nsIContent* container = insertion.mParentFrame->GetContent();
nsIAtom* frameType = insertion.mParentFrame->GetType();
LAYOUT_PHASE_TEMP_EXIT();
if (MaybeRecreateForFrameset(insertion.mParentFrame, aStartChild, aEndChild)) {
@@ -8014,7 +8012,6 @@ nsCSSFrameConstructor::ContentRangeInserted(nsIContent* aContainer,
return;
}
container = insertion.mParentFrame->GetContent();
frameType = insertion.mParentFrame->GetType();
}
}
@@ -8087,49 +8084,6 @@ nsCSSFrameConstructor::ContentRangeInserted(nsIContent* aContainer,
}
}
// If the parent of our current prevSibling is different from the frame we'll
// actually use as the parent, then the calculated insertion point is now
// invalid and as it is unknown where to insert correctly we append instead
// (bug 341858).
// This can affect our prevSibling and isAppend, but should not have any
// effect on the WipeContainingBlock above, since this should only happen
// when neither parent is a ib-split frame and should not affect whitespace
// handling inside table-related frames (and in fact, can only happen when
// one of the parents is a table wrapper and one is an inner table or when the
// parent is a fieldset or fieldset content frame). So it won't affect the
// {ib} or XUL box cases in WipeContainingBlock(), and the table pseudo
// handling will only be affected by us maybe thinking we're not inserting
// at the beginning, whereas we really are. That would have made us reframe
// unnecessarily, but that's ok.
// XXXbz we should push our frame construction item code up higher, so we
// know what our items are by the time we start figuring out previous
// siblings
if (prevSibling && frameItems.NotEmpty() &&
frameItems.FirstChild()->GetParent() != prevSibling->GetParent()) {
#ifdef DEBUG
nsIFrame* frame1 = frameItems.FirstChild()->GetParent();
nsIFrame* frame2 = prevSibling->GetParent();
NS_ASSERTION(!IsFramePartOfIBSplit(frame1) &&
!IsFramePartOfIBSplit(frame2),
"Neither should be ib-split");
NS_ASSERTION((frame1->GetType() == nsGkAtoms::tableFrame &&
frame2->GetType() == nsGkAtoms::tableWrapperFrame) ||
(frame1->GetType() == nsGkAtoms::tableWrapperFrame &&
frame2->GetType() == nsGkAtoms::tableFrame) ||
frame1->GetType() == nsGkAtoms::fieldSetFrame ||
(frame1->GetParent() &&
frame1->GetParent()->GetType() == nsGkAtoms::fieldSetFrame),
"Unexpected frame types");
#endif
isAppend = true;
nsIFrame* appendAfterFrame;
insertion.mParentFrame =
::AdjustAppendParentForAfterContent(this, container,
frameItems.FirstChild()->GetParent(),
aStartChild, &appendAfterFrame);
prevSibling = ::FindAppendPrevSibling(insertion.mParentFrame, appendAfterFrame);
}
if (haveFirstLineStyle && insertion.mParentFrame == containingBlock && isAppend) {
// It's possible that the new frame goes into a first-line
// frame. Look at it and see...