The patch in bug 635240 sets "display:block" for input[type=number]::-moz-spin-up/down in forms.css, since otherwise the anonymous divs that these pseudo-elements refer to do not get laid out correctly. According to dholbert this should not be necessary though (see bug 635240 comment 17 and the end of comment 18).
So, if I take "display: block" out of the moz-spin-up or moz-spin-down style, I can confirm (from framedumps) that they get wrapped in an anonymous flex item. So, we're not coercing the display to be block typed. This is because we create the nsStyleContext with aSkipFlexItemStyleFixup = true, because ResolvePseudoElementStyle passes in a flag "eSkipFlexItemStyleFixup" that tells us to do that, per this chunk of code... > 1377 // Flex containers don't expect to have any pseudo-element children aside > 1378 // from ::before and ::after. So if we have such a child, we're not > 1379 // actually in a flex container, and we should skip flex-item style fixup. > 1380 flags |= eSkipFlexItemStyleFixup; http://mxr.mozilla.org/mozilla-central/source/layout/style/nsStyleSet.cpp?rev=9f50f1e05bfd#1377 ...and I guess that code-comment is technically wrong, in this case. The reason behind that current code is laid out in bug 812822 comment 23. (particularly the second paragraph, about elements with a mandated frame type which could be restyled to "display: flex" but aren't actually flex containers) So I guess part of that comment's premise is wrong -- flex containers *can* have pseudo-element children, when the container itself is an anonymous widget control with pseudo-elements provided for authors to style each chunk. So maybe we need a better way to exempt elements with mandated frame-types (like <button> / <fieldset> / <legend>) from getting flex-item fixup on their children, when someone casually sets "display:flex" on them.