Loading the testcase triggers: ###!!! ASSERTION: containing block height must be constrained: 'containingBlockHeight != NS_AUTOHEIGHT', file mozilla/layout/generic/nsHTMLReflowState.cpp, line 1060 ###!!! ASSERTION: unexpected 'containing block height': 'NS_AUTOHEIGHT != aContainingBlockHeight', file mozilla/layout/base/nsLayoutUtils.cpp, line 1670 ###!!! ASSERTION: unexpected height value: 'aCoord.GetUnit() == eStyleUnit_None || aCoord.GetUnit() == eStyleUnit_Auto', file mozilla/layout/base/nsLayoutUtils.cpp, line 1678 Probably related to bug 382610. Since this testcase doesn't involve -moz-appearance, I imagine it's more likely to be reproducible cross-platform.

Worksforme on current Linux trunk...

Still happens for me on Mac trunk.

Ok, I can reproduce on Mac. This is basically the same bug as bug 382610. Basically, nsFileControlFrame::Reflow does a second reflow in some cases (apparently I wasn't hitting these on Linux). It does some really bizarre things in terms of constructing the reflow state for this second pass, as well as the calling order of DidReflow, etc. That's the root of this bug...

We should really figure out what that code is trying to do and make it sane...

What symptoms does this have that make it deserve to be a blocker?

Any effect would be in the vertical sizing of the parts of a file input. I guess with native theming all that is already broken enough that this bug really doesn't make it any worse... Removing nomination.

I think this is fixed by the patch that just landed for bug #363696.

Yeah, indeed.

Crashtest checked in.