Bug 85490 – Nested CSS flexbox renders flexbox items outside the containing block

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: CSS

[Victor Carbune]

Created attachment 139998 [details]
ComparisonScreenshot

Context layout, main flexbox container:
* Flexbox Item 1 has flex: 1, and is itself a flexbox, with two divs as flexbox items.
* Flexbox Item 2 which is just a div with text.

Both flexbox containers have direction set to 'column' and alignment set to 'end'

Problem:
The two divs of are rendered outside the containing block.

This only happens with -webkit-flexbox, not with -webkit-box.

[Victor Carbune]

Created attachment 139999 [details]
html pages

[Tony Chang]

Sorry, I was on out the last few weeks.  I'll take a look at this today.

[Tony Chang]

Err, I meant to write that on bug 83572.  This may be the same bug.

[Caio Marcelo de Oliveira Filho]

Looking at the code, it seems strange to me that RenderFlexibleBox::computeAvailableFreeSpace(), when the flexbox have an override height (which I'm guessing was set by the outer flexbox in this case), we don't take in account the preferredMainAxisSize when returning.

However, even subtracting the preferredMainAxisSize, the content is still not correctly positioned, the bottom margins seems to be not counted here, so the Text Line 2 is too close to the edge.


Tony or Ojan, I'm also trying to turn this into a layout test. Is changing the text nodes into divs with predictable size and checking offset{Top,Bottom,Height,Width} be a good approach?

[Tony Chang]

Yup, this is the same bug.

(In reply to comment #4)
> Looking at the code, it seems strange to me that RenderFlexibleBox::computeAvailableFreeSpace(), when the flexbox have an override height (which I'm guessing was set by the outer flexbox in this case), we don't take in account the preferredMainAxisSize when returning.
> 
> However, even subtracting the preferredMainAxisSize, the content is still not correctly positioned, the bottom margins seems to be not counted here, so the Text Line 2 is too close to the edge.

Right, we need to also subtract the padding, border and scrollbar size.  I.e., it's the difference between content height and height.

> 
> Tony or Ojan, I'm also trying to turn this into a layout test. Is changing the text nodes into divs with predictable size and checking offset{Top,Bottom,Height,Width} be a good approach?

I have a fix for this.  I'll include a similar case in my layout test.

*** This bug has been marked as a duplicate of bug 83572 ***