Tagging with current canary milestone for further triaging.

For the recording -- looks like that is a different testcase? Hard to comment on that without seeing it...

Two comments on the provided testcase:
- You definitely need box-sizing: border-box; if you want 100% to match the exact size (iframes have a border by default which would otherwise overflow the container)
- There may be an issue here related to min-height handling. You can certainly work around this by specifying min-height: 0; on the flex item but I think there's an actual bug here.

Tried to reproduce video bug in codepen, but couldn't. 
Noticed another thing. I think that behaviour has changed since I reported this. Now when I open sample, it's height is correct, but try changing preview window height and it breaks. min-height: 0 also didn't prevent this. 

Anyway, I don't need workarounds for this as I did one already, thanks!

That's weird that min-height: 0 did not prevent it -- it definitely does for me. That's on the .flexitem{} rule.

*sigh* this bug is tricky. When we relayout the flexbox, we get to this code:
  if (layoutType != NeverLayout && childHasIntrinsicMainAxisSize(child) &&
      child.needsLayout()) {
    child.clearOverrideSize();
    child.forceChildLayout();

But the child does not need layout, so we don't force this layout. We then access intrinsicContentLogicalHeight() later on for the min-height calculation, but that is "invalid" because the child iframe's percentage size affected that sizing. I don't really know how to fix this... we could avoid updating intrinsicContentLogicalHeight if we're stretched, but that doesn't really solve the issue because an ancestor could be the one getting stretched and that causes the same problem. We could also force layout children in this case but that seems like it could be very slow (we already force a similar layout in layoutAndPlaceChildren and we would have to keep that one *as well*)

I don't actually know why we relayout the flexbox itself, though -- seems like we shouldn't need to?

@cbiesin my mistake, I guess I put that rule to container before, because now it worked!

Thanks for confirming!