1036404 - [css3-flex] flex container has wrong baseline, with "overflow: hidden" and "align-items: baseline"

Status: VERIFIED DUPLICATE of bug 969874

(Core :: Layout, defect)

Description

[Leevi Graham]

Attachment: flex-example.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36

Steps to reproduce:

Nested a H1 and a UL flexbox inside of another flexbox.


Actual results:

The LI's in the UL were not aligned to the H1 baseline


Expected results:

The LI's in the UL should have been aligned to the H1 baseline

Comment 1

[Leevi Graham]

Quick pen example as well: http://codepen.io/leevigraham/pen/ejuLH

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Here's a reduced testcase.

Basically, we're treating flex containers with "overflow:hidden" (overflow:[non-visible], really) as if their baseline is the bottom of the content area.

The problem goes away if you remove "overflow:hidden".

In Chrome, 'overflow' doesn't seem to impact the baseline. Not sure what the correct behavior is, but I'm willing to believe that we're wrong.

Comment 3

[Daniel Holbert [:dholbert]]

So when our flex container is overflow:[non-visible], it gets nested inside of a nsHTMLScrollFrame, which reflows it via nsHTMLScrollFrame::ReflowContents (which calls ReflowScrolledFrame, which calls nsFlexContainerFrame::Reflow).

It looks like nsFlexContainerFrame::Reflow() returns the correct baseline via the nsHTMLReflowMetrics::mBlockStartAscent outparam, but then nsHTMLScrollFrame ignores it (when really, it should be copying it into its own nsHTMLReflowMetrics outparam).

Comment 4

[Leevi Graham]

Thanks for debugging this so quickly Dan. Not knowing the Firefox internals I only partially followed your explanation :)

I've created another test case which again demonstrates the issue of overflow:[non-visible] on an element with display:flex. It also demonstrates what I was originally trying to achieve ie text-overflow:ellipsis.

http://codepen.io/leevigraham/pen/ejuLH

Out of curiosity is this an easy thing to fix? It's pretty easy to code around in CSS.

Cheers Leevi

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Leevi Graham from comment #4)
> I've created another test case which again demonstrates the issue of
> overflow:[non-visible] on an element with display:flex. It also demonstrates
> what I was originally trying to achieve ie text-overflow:ellipsis.
> 
> http://codepen.io/leevigraham/pen/ejuLH

You say this demonstrates the issue, but I don't see any obvious issues there -- everything seems baseline-aligned. Can you elaborate? (Maybe the codepen is just intended as a reference case?)

(Note that this codepen URL is actually the exact same URL from comment 1, though the content behind it has changed. I guess codepen URLs aren't guaranteed-to-be-static. This is a one of the reasons it's nice to post testcases as attachments on bugzilla [as you did when filing this bug -- thanks!], rather than referencing external URLs to dynamically-changing content. :)  Hence, maybe worth posting the contents of your codepen as an attachment on this bug page, if you think it's worth it & you don't mind.)

> Out of curiosity is this an easy thing to fix? It's pretty easy to code
> around in CSS.

I don't think it should be too bad, but I haven't worked with scroll-frames too much (the layer added by "overflow:[non-visible]" that's causing the trouble), so there may be complexity and/or extra fallout there that I'm not appreciating.

I probably won't get to fixing this right away -- I've got some other higher-priority flexbox work on my plate at the moment -- so if this isn't too bad to work around, I'd probably recommend doing that for the time being.

Comment 6

[Leevi Graham]

> You say this demonstrates the issue, but I don't see any obvious issues there 
> -- everything seems baseline-aligned. 
> Can you elaborate? (Maybe the codepen is just intended as a reference case?)

Yes you're right. The  link I posted is the expected result. I was trying to demonstrate your point that setting overflow: visible does work around the issue.

Thanks again for confirming the issue and looking into it. I'll keep an eye out for the fix (sometime in the future :) )

Comment 7

[Daniel Holbert [:dholbert]]

Actually, I think this is the same as bug 969874. Marking as a duplicate.