794644 - Overflow auto not working as expected for display table-row

Status: UNCONFIRMED

(Core :: Layout, defect)

Description

[Theo Cushion]

Attachment: index.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_0) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4

Steps to reproduce:

Attempting to create a layout where by there is a variable height sticky header, variable height sticky footer and content that fills the remaining space in-between. If the content is too big to fit in the view port then the centre section should scroll.

The attached code works in webkit browsers, but does not work in Firefox. It's unclear what is the correct behaviour, but intuitively it seems like overflow: auto should not be ignored in this example.


Actual results:

The entire view port scrolls when the view port is too small for the centre section to be entirely displayed - pushing the footer out of the view port.


Expected results:

The centre section should scroll (overflow auto) when the content exceeds the size of the centre section - meaning that the header and footer stay at the top and bottom of the view port.

Comment 1

[Matthias Versen [:Matti]]

Gecko trunk and Opera12 show the same behavior

Comment 2

[Theo Cushion]

Attachment: Example where WebKit and Gecko have the same behaviour

Comment 3

[Theo Cushion]

With the testcase https://bugzilla.mozilla.org/attachment.cgi?id=665319, both WebKit and Gecko show the same behaviour - not allowing overflow.

However, if `.l-fit-height-row-content` is changed to `display: block` then WebKit will exhibit the desired behaviour, but Gecko will render it in exactly the same fashion.

Comment 4

[Boris Zbarsky [:bzbarsky]]

That first testcase is relying on a WebKit bug.  In particular, <div class="l-scroll-content"> has 100% height, but its parent is auto height, so the height on the child should also compute to "auto".  And therefore it should not overflow...  WebKit does weird things with percent-height kids of auto-height table rows in some cases that don't follow the spec.

Comment 5

[Martin Häcker]

We've run into the same bug where we can get the desired layout (as described in the bug) in Webkit but not in Firefox - if this is relying on a bug, whats the correct way to achieve this layout?

Comment 6

[Theo Cushion]

Martin Häcker: We've solved the issue like so http://stackoverflow.com/a/12622740/101515

Comment 7

[Martin Häcker]

Wow thanks!