Open Bug 381497 Opened 13 years ago Updated 2 years ago
page area not initial containing block for print
Overview: According to CSS2.1, the page area of the page box is the initial containing block. That means a 100% height on the <html> element should make the <html> element take up the entire first page. We seem to have an initial containing block with 'auto' height. Steps to Reproduce: Open up testcase in Print Preview (or print it) Expected Results: Gray borders down the side of the entire first page, but not past it, and a blue border followed by text on the second page. Actual Results: All text and blue border at top of first page, gray borders only as tall as the text content. Tested on a trunk source build 2007-05-21 on Linux.
So I'm looking at the code and it seems we set the initial containing block to be the HTML element's frame. That doesn't seem right. It might be why we're failing some other initial containing block tests like those in http://lists.w3.org/Archives/Public/public-css-testsuite/2005May/0004.html We probably want the root viewport frame to be the initial containing block. Does that seem correct?
Which code are you looking at, exactly? Is this related to bug 243519 and its dependencies, or a separate issue?
I was looking at nsCSSFrameConstructor::ConstructRootFrame. This bug seems related in that it seems the right way to fix it could wind up fixing both. I mean, I could probably hack nsPageContentFrame to fix the height: 100% problem here, but it seems to me the essential problem is that we have the wrong mInitialContainingBlock in nsCSSFrameConstructor, and that's probably causing bug 243519 &co as well. Although for print we might need the initial containing block to be the pageContentFrame or something else rather than the root viewportFrame.
Attachment #265561 - Attachment mime type: text/xhtml+xml → application/xhtml+xml
12 years ago
Requesting blocking, because I think this bug is the root cause of the P2/blocking1.9+ bug 411382
Based on Comment 4 we should fix this
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
This one already passes.
I think we can remove this from the blocking list now that bug 411382 is fixed. (That covers the first two testcases here.)
Assignee: fantasai.bugs → nobody
fantasai, your tests seem to WFM. Do you think there's anything we're missing or is this bug WFM?
Seems to work for me, too! Might want to have the tests make their way into WPT, though. Not sure what's the best process for tracking that?
You need to log in before you can comment on or make changes to this bug.