856235 - "ASSERTION: this type of frame can't have overflow containers" and abort with -moz-column, flex

Status: RESOLVED DUPLICATE of bug 1622935

(Core :: Layout, defect)

Description

[Jesse Ruderman]

Attachment: testcase (crashes Firefox when loaded)

###!!! ASSERTION: this type of frame can't have overflow containers: '(aProperty != nsContainerFrame::OverflowContainersProperty() && aProperty != nsContainerFrame::ExcessOverflowContainersProperty()) || IsFrameOfType(nsIFrame::eCanContainOverflowContainers)', file layout/generic/nsContainerFrame.cpp, line 1468

###!!! ABORT: unexpected frame type: file layout/base/nsCSSFrameConstructor.cpp, line 8785

Nightly: Crash bp-3780ba87-7e00-40f2-9cad-8c4022130330 (somewhat busted stack)

Comment 1

[Jesse Ruderman]

Attachment: assertion stacks

Comment 2

[Jesse Ruderman]

Oh, "unexpected frame type" is a NS_RUNTIMEABORT, so the nightly stack isn't as busted as I thought.

Comment 3

[Jesse Ruderman]

Attachment: asan opt stack

Comment 4

[Mats Palmgren (inactive)]

WFM, trunk and beta debug builds on Linux64 and trunk debug build on OSX.

Comment 5

[Daniel Holbert [:dholbert]]

I can still repro in Nightly, on linux, with up-to-date nightly. (build ID 20130515141643)

 bp-97596fc8-d1c2-4e08-8b51-4e1e72130516

I'll take a closer look at this.

Comment 6

[Mats Palmgren (inactive)]

That's odd, I wouldn't expect a difference between Opt/Debug builds for the
NS_RUNTIMEABORT.  Would be good if you can figure out why that happened...

Comment 7

[Daniel Holbert [:dholbert]]

(I'm not actually seeing a difference between opt/debug builds, on my machine. My Nightly build crashes, and my debug build does as well.)

Comment 8

[Daniel Holbert [:dholbert]]

So what's going on here is:
 - Flexbox doesn't currently support pagination (working on that in bug 811024)
 - It conveys that to its children by passing them NS_UNCONSTRAINEDSIZE availableHeight.
 - **However** it doesn't do that for its *absolutely-positioned* children. Those guys get reflowed in the FinishReflowWithAbsoluteFrames() call, which doesn't have any special availableHeight behavior.

The right fix is just to fix bug 811024, and given that this is a safe crash (via NS_RUNTIMEABORT), it's probably not worth landing a bandaid.  However, for the record, one strawman bandaid would be to just pass a tweaked nsHTMLReflowState to FinishReflowWithAbsoluteFrames, with availableHeight manually set to NS_UNCONSTRAINEDSIZE.

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: strawman patch

Here's a strawman patch per end of prev. comment, using a Maybe<> stack-allocated nsHTMLReflowState that's a mutable clone of the existing one. (basically following what we do towards the beginning of nsBlockFrame::Reflow, here: https://mxr.mozilla.org/mozilla-central/source/layout/generic/nsBlockFrame.cpp#909 )

But I think it's probably better to just let this be fixed by bug 811024.

Comment 10

[Carsten Book [:Tomcat]]

btw bughunter also run into some websites with this abort

Comment 11

[Jesse Ruderman]

Tomcat, do those sites use CSS flex properties?  If not, please file a separate bug.

Comment 12

[Daniel Holbert [:dholbert]]

I can still reproduce this in trunk; it likely depends on bug 939897 now (which was spun off of bug 811024).

Comment 13

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

I cannot reproduce this on my local debug build or on Nightly. Bug 1622935 implemented flex item fragmentation. Specifically, Bug 1622935 Part 3 allow flex container being an overflow container. I believe we can dup this over bug 1622935.