We fail this WPT test:
https://wpt.fyi/results/css/css-flexbox/percentage-heights-013.html

Specifically the last subtest, which we render with the flex item's child as having a height of 19px when the test expects 150px.

This seems to be because the test is expecting that this element -- an unrecognized embed -- will honor percent heights. We seem to render the embed as an empty inline element (equivalent to a span). Chrome renders a big plugin-not-recognized graphic.

The choice of "empty inline element" vs big graphic seems to be the relevant difference here; I'm not sure that's well-specified? I'd need to check the html spec. But we can also avoid that dependency by just putting display:block on the embed element, so that its percent height will have a better chance of attempting to resolve (rather than being ignored if the embed renders as an empty inline).

Notably, the test also uses type="application/x-webkit-test-webplugin" for that embed element, which looks pretty-obviously like a WebKit/Blink specific non-standard magic token.

But I don't think it's depending too strongly on that, since I see the same results in Chrome if I use type="application/x-lol"

Here's a trivial testcase for this scenario:

data:text/html,<embed style="border: 3px solid black" type="application/x-lol">

In Firefox, that renders just like the following:

data:text/html,<span style="border: 3px solid black">

...whereas in Chrome, it renders with a 300x150 image saying "This plugin is not supported".

(In reply to Daniel Holbert [:dholbert] from comment #0)

The choice of "empty inline element" vs big graphic seems to be the relevant difference here; I'm not sure that's well-specified? I'd need to check the html spec.

Quick check:

• It seems this corresponds to the scenario when the html spec's "Determine the type of the content" algorithm returns null (i.e. doesn't recognize the type).
• That makes the embed setup steps decide to "Display no plugin for element."
• The "Display no plugin" process says "Display an indication that no plugin could be found for element, as the contents of element."

So it seems that Chrome is correct to display some indication. Having said that, the indication itself doesn't seem well-defined -- e.g. it's not obvious that it should honor percent heights when display:inline. So I think it still makes sense to change the test to use display:block on the embed element, to make the assumption about it honoring percentages more valid.

It looks like the whatwg HTML-spec behavior here (calling for "an indication that no plugin could be found") was added in https://github.com/whatwg/html/commit/d0b092530e62aa88cae7f63657098b411eb09b01#diff-41cf6794ba4200b839c53531555f0f3998df4cbb01a4d5cb0b94e3ca5e23947dR30531 to address https://github.com/whatwg/html/issues/3876 , FWIW.

qdot noted our no "Missing Plugin" UI behavior in https://github.com/whatwg/html/issues/3876#issue-347139617 (pending a bug that was in the process of landing at that point)

They noted in https://github.com/whatwg/html/issues/3876#issuecomment-412930729 that they "didn't realize that was suppose to go to "unsupported plugin". That'll take a bit more logic on our end but I think is doable."

(I guess we never ended up with a bug on making that change to our embed handling.)

So: tl;dr, I suspect we should land a patch to adjust the test to add display:inline-block to the embed element so that it's clearly not an empty inline; and then we should file a separate bug on achieving interop (and perhaps further-clarifying the spec expectations) on displaying some sort of "missing plugin" UI for unrecognized embed type attributes.

Browsers aren't currently interoperable on what the fallback rendering is for
embed elements with unrecognized 'type' attributes. Firefox renders them as an
empty inline element (like an empty 'span'), whereas other browsers render them
as a fallback graphic with the 300x150 default replaced-element size.

We should probably try to achieve interop on this embed fallback behavior, but
it's not relevant to what this test is testing, which is whether percentage
heights can be resolved on children-of-flex-items. Percentages in fact do
resolve properly here, in all browsers. But the last subtest is failing in
Firefox before this patch, simply because we're treating the embed as an empty
inline element -- and consequently, we're ignoring its 'height' property
entirely, just like we do on e.g. inline-level 'span'.

This patch works avoids tripping over this 'embed' fallback-behavior behavioral
difference by forcing the embed element to be 'display: inline-block', which
makes its height property be recognized and honored.

(In reply to Daniel Holbert [:dholbert] from comment #3)

(I guess we never ended up with a bug on making that change to our embed handling.)
(In reply to Daniel Holbert [:dholbert] from comment #4)
we should file a separate bug on achieving interop (and perhaps further-clarifying the spec expectations) on displaying some sort of "missing plugin" UI for unrecognized embed type attributes.

Filed as bug 1849262.

https://hg.mozilla.org/mozilla-central/rev/8c2cc594742c