1183896 - Crash with table, position:sticky

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Jesse Ruderman]

Attachment: testcase (crashes Firefox)

Comment 1

[Jesse Ruderman]

Attachment: stack

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase that actually crashes

Comment 3

[Boris Zbarsky [:bzbarsky]]

So the problem is that nsTableRowFrame::ReflowChildren is doing this:

994             LogicalMargin computedOffsets(wm, *static_cast<nsMargin*>
995               (kidFrame->Properties().Get(nsIFrame::ComputedOffsetProperty())));

but nsIFrame::ComputedOffsetProperty() returned null in this case.  kidFrame is an nsTableCellFrame....

Looks like StickyScrollContainer::ComputeStickyOffsets or nsHTMLReflowState::ComputeRelativeOffsets is supposed to set this prop.

In this case, the latter doesn't because we're not position:relative, and the former never happens because of bug 975644, which means we never reach ComputeStickyOffsets for table-internal stuff.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: Don't assume that relatively positioned table cells actually have positioned offsets computed, because in the case of position:sticky they don't

Comment 5

[Daniel Holbert [:dholbert]]

Comment on attachment 8634272 [details] [diff] [review]
Don't assume that relatively positioned table cells actually have positioned offsets computed, because in the case of position:sticky they don't

r=me

Comment 6

[Daniel Holbert [:dholbert]]

(BTW: the contextual code changed a little, but this patch still applies correctly with fuzz.)

Comment 7

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8472aae68d5c

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/8472aae68d5c