When we crash, the aParentContext pointer passed to nsStyleSet::ResolveAnonymousBoxStyle is 0xf0dea7ff (so frame poison).
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.
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?
Created attachment 422482 [details] [diff] [review] 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.
Assignee: nobody → tnikkel
Attachment #422482 - Flags: review?(bzbarsky)
Comment on attachment 422482 [details] [diff] [review] patch s/principle/principal/ and looks good.
Attachment #422482 - Flags: review?(bzbarsky) → review+
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
This does something very similar to (one half of) bug 533379, so if we take this on branch we would want that too.
Crash Signature: [@ nsStyleContext::FindChildWithRules]
Landed the crash test: https://hg.mozilla.org/integration/mozilla-inbound/rev/56e9f8640762
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.