Created attachment 163439 [details] testcase We compute them to the size of the content of the body element. Opera and Firefox walk up to the html element to find the height of the html element or use the window's height if the html element doesn't have a fixed height.
IE9 also matches Opera/Firefox.
Created attachment 163480 [details] Patch
Comment on attachment 163480 [details] Patch Attachment 163480 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/13818660 New failing tests: tables/mozilla/core/cell_heights.html fast/table/height-percent-test.html tables/mozilla_expected_failures/bugs/bug19526.html fast/block/basic/quirk-height.html tables/mozilla_expected_failures/bugs/bug85016.html tables/mozilla/core/table_heights.html
Comment on attachment 163480 [details] Patch Attachment 163480 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/13818667 New failing tests: tables/mozilla/core/cell_heights.html fast/table/height-percent-test.html tables/mozilla_expected_failures/bugs/bug19526.html fast/block/basic/quirk-height.html tables/mozilla_expected_failures/bugs/bug85016.html tables/mozilla/core/table_heights.html
Comment on attachment 163480 [details] Patch nm. This is causing genuine test failures.
Created attachment 163912 [details] Patch
Comment on attachment 163912 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=163912&action=review > Source/WebCore/rendering/RenderBox.cpp:2136 > + while (!cb->isRenderView() && !cb->isTableCell() && !cb->isOutOfFlowPositioned() && cb->style()->logicalHeight().isAuto() && isHorizontalWritingMode() == cb->isHorizontalWritingMode()) { > if (!document()->inQuirksMode() && !cb->isAnonymousBlock()) > break; In quirks mode, it looks like it's possible for cb to be NULL now. How do we exit this loop? > Source/WebCore/rendering/RenderBox.cpp:2138 > + rootMarginBorderPaddingHeight += cb->marginBefore() + cb->marginAfter() + cb->borderAndPaddingLogicalHeight(); Why do we subtract the margin? It shouldn't be in cb's height. Can you add a test where you set the margin? > LayoutTests/fast/css/percentage-height-auto-sized-body-quirks.html:8 > +<body onload="checkLayout('#item')"> What about a percentage height on body when in standards mode? It should still check the <html> element, right? Can you add a test for that?
Created attachment 163972 [details] Patch
Comment on attachment 163912 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=163912&action=review > Source/WebCore/rendering/RenderBox.cpp:2136 > break; I think we always hit the !cb->isRenderView() case. Do we ever have an root renderbox (i.e. html element) that is not contained in a RenderView? >> Source/WebCore/rendering/RenderBox.cpp:2138 >> + rootMarginBorderPaddingHeight += cb->marginBefore() + cb->marginAfter() + cb->borderAndPaddingLogicalHeight(); > > Why do we subtract the margin? It shouldn't be in cb's height. Can you add a test where you set the margin? The root and body elements are special because we skip over them and grab the height of the renderview, which doesn't correctly subtract the margins on the body/html elements. This matches other browsers. The body element by default has a margin, so that is tested already in the new test. I thought I added a test with margin on the HTML element, but apparently not. Added it to the existing test. >> LayoutTests/fast/css/percentage-height-auto-sized-body-quirks.html:8 >> +<body onload="checkLayout('#item')"> > > What about a percentage height on body when in standards mode? It should still check the <html> element, right? Can you add a test for that? I could, but this code literally has no effect on standards mode since the first thing the for loop does is break if we're in quirks mode. It's on my TODO list to merge that into the for-loop condition to make that more clear. Anyways, I'm pretty sure we have test coverage of this already.
Comment on attachment 163912 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=163912&action=review >>> Source/WebCore/rendering/RenderBox.cpp:2136 >>> break; >> >> In quirks mode, it looks like it's possible for cb to be NULL now. How do we exit this loop? > > I think we always hit the !cb->isRenderView() case. Do we ever have an root renderbox (i.e. html element) that is not contained in a RenderView? What happens in a DocumentFragment?
Comment on attachment 163972 [details] Patch (In reply to comment #10) > (From update of attachment 163912 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=163912&action=review > > >>> Source/WebCore/rendering/RenderBox.cpp:2136 > >>> break; > >> > >> In quirks mode, it looks like it's possible for cb to be NULL now. How do we exit this loop? > > > > I think we always hit the !cb->isRenderView() case. Do we ever have an root renderbox (i.e. html element) that is not contained in a RenderView? > > What happens in a DocumentFragment? Ojan tells me that DocumentFragment's don't have a render tree, so they don't go through this code path.
Committed r128517: <http://trac.webkit.org/changeset/128517>