Closed Bug 852408 Opened 12 years ago Closed 12 years ago

Don't reframe on removals of the prev sibling of a table pseudo unless its prev sibling is also a table pseudo

Categories

(Core :: Layout, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla22

People

(Reporter: bzbarsky, Assigned: bzbarsky)

Details

Attachments

(2 files)

We have some XXX comments about doing this dating back to when GetPrevSibling didn't exist on frames.
Attached patch Same as diff -w (deleted) — Splinter Review
Just to be sure I understand -- is this code trying to figure out whether we need to merge the implicit row frames around the naked <td>'s in a case like this, when the explicit <tr> is removed? <table> <td></td> <tr id="removeMe">...</tr> <td></td> </table> ?
OS: Mac OS X → All
Hardware: x86 → All
Version: unspecified → Trunk
Comment on attachment 726490 [details] [diff] [review] Don't reframe the parent if a frame whose next sibling is a table pseudo is removed, unless its prev sibling is also a table pseudo. [proceeding assuming the answer is at least approximately "yes"] >@@ -9277,16 +9288,18 @@ nsCSSFrameConstructor::MaybeRecreateCont > // Now check for possibly needing to reconstruct due to a pseudo parent > nsIFrame* inFlowFrame = > (aFrame->GetStateBits() & NS_FRAME_OUT_OF_FLOW) ? > GetPlaceholderFrameFor(aFrame) : aFrame; > NS_ASSERTION(inFlowFrame, "How did that happen?"); >+ MOZ_ASSERT(inFlowFrame == inFlowFrame->GetFirstContinuation(), >+ "placeholder for primary frame has previous continuations?"); > nsIFrame* parent = inFlowFrame->GetParent(); Might as well upgrade the existing NS_ASSERTION to a MOZ_ASSERT there, to avoid having back-to-back different assertion flavors. Also, this way, if the first assertion ever fails, we'll abort early, rather than crashing while trying to evaluate "inFlowFrame->GetFirstContinuation()" in your added MOZ_ASSERT condition (as we would w/ your current patch) >+ // Good enough to recreate frames for aFrame's parent's content; even if >+ // aFrame's parent is a table pseudo, that'll be the right content node. >+ *aResult = RecreateFramesForContent(parent->GetContent(), true); >+ return true; Fix indentation on the first line of the comment there.
Attachment #726490 - Flags: review?(dholbert) → review+
er... s/first line/second line/ [of the comment]
> is this code trying to figure out whether we need to merge the implicit row frames > around the naked <td>'s If your markup is XHTML, not XML, then yes. Or merge the implicit tables in this case: <div style="display: table-cell">a</div> <div>b</div> <div style="display: table-row">c</div> when the middle div is removed. > Might as well upgrade the existing NS_ASSERTION to a MOZ_ASSERT there Done. > Fix indentation on the first line of the comment there. Done, on the second line.
Whiteboard: [need review]
Whiteboard: [need landing]
Flags: in-testsuite-
Whiteboard: [need landing]
Target Milestone: --- → mozilla22
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: