<button> is not implementable (by browsers) in pure CSS, so they are a
bit of a black box, from the perspective of CSS. This means that they
don't necessarily react in the same way that e.g. a <div> would.
This isn't specific to flexbox -- e.g. we don't render scrollbars if
you put overflow:scroll on a button, and we don't render it as a
table if you put display:table on it.
Stepping back even further, this isn't specific to <button>. Consider
<fieldset> and <table> which also have special rendering behavior:
data:text/html,<fieldset style="display:flex"><div>abc</div><div>def</div>
In these cases, Chrome agrees with us and disregards the flex
display mode. (as revealed by the fact that "abc" and "def" end up
being stacked vertically). The fact that they happen to do what you're
expecting on <button style="display:flex"> is likely just due to an
implementation detail.
In Gecko's button implementation, we hardcode <button> (and
<fieldset>, and <table>) as having a specific frame class (and hence,
a specific way of laying out the child elements), regardless of the
display property.
If you want to reliably have the children reliably arranged in a
particular layout mode in a cross-browser fashion, your best bet is to
use a wrapper-div inside the button, just as you would need to inside
of a <table> or a <fieldset>.
Therefore, that bug was marked as "resolved invalid".
