537645 - Crash [@ nsStyleContext::FindChildWithRules] with -moz-column, spacer, caption

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Jesse Ruderman]

Attachment: testcase (crashes when loaded)

Comment 1

[Jesse Ruderman]

Attachment: stack trace

Comment 2

[Boris Zbarsky [:bzbarsky]]

When we crash, the aParentContext pointer passed to nsStyleSet::ResolveAnonymousBoxStyle is 0xf0dea7ff (so frame poison).

Comment 3

[Boris Zbarsky [:bzbarsky]]

And that happens because providerFrame is poisoned.

aFrame as passed to ReResolveStyleContext is a -moz-anonymous-block pseudo-frame.  Its IBPreviousSibling pointer is pointing to providerFrame (as expected), and that frame is NOT in the frametree.

Comment 4

[Boris Zbarsky [:bzbarsky]]

If don't run the onload handler, then the ib inlines are also missing from the frame tree.

If I don't put a margin on "span", then they're present in the frametree, as expected.

Breaking on nsFrame::DestroyFrom methods, it looks like the ib prevsibling is destroyed from nsContainerFrame::DestroyOverflowList called from nsContainerFrame::Destroy called from nsBlockFrame::DeleteNextInFlowChild.  And in particular, we're destroying the next-in-flow of the frame which parents the <spacer> and the inline-table which wraps the <caption>.  This is the ib first sibling for the outer span; the ib first siblings for the inner two nested spans seem to be on the overflow list of this continuation we're deleting, with the result that we kill them off.

roc, mats, tn, any idea what's going on here?

Comment 5

[Timothy Nikkel (:tnikkel)]

Regression range
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e95fb8b811ac&tochange=76540a65adc0

Comment 6

[Timothy Nikkel (:tnikkel)]

Attachment: patch

In nsInlineFrame::ReflowFrames for the first continuation of the most outer span, after reflowing all of our frames we try to pull frames from next in flows with PullOneFrame. As in comment 4, the next in flow has the first (inline) part of the ib-split on its overflow list and no frames on its principle childlist. So we skip over it and look in the next continuation. Bug 533379 fixed a similar problem if PullOneFrame removed the last frame from the principle childlist. But in this case the principle childlist starts out empty.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 422482 [details] [diff] [review]
patch

s/principle/principal/ and looks good.

Comment 8

[Timothy Nikkel (:tnikkel)]

http://hg.mozilla.org/mozilla-central/rev/5e029b7c846c

Comment 9

[Timothy Nikkel (:tnikkel)]

This does something very similar to (one half of) bug 533379, so if we take this on branch we would want that too.

Comment 10

[Mats Palmgren (inactive)]

Landed the crash test:
https://hg.mozilla.org/integration/mozilla-inbound/rev/56e9f8640762

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/56e9f8640762