Open Bug 381497 Opened 13 years ago Updated 2 years ago

page area not initial containing block for print

Categories

(Core :: Printing: Output, defect)

defect
Not set

Tracking

()

People

(Reporter: fantasai.bugs, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(4 files)

1.08 KB, application/xhtml+xml
Details
529 bytes, text/html
Details
338 bytes, text/html
Details
251 bytes, text/html
Details
Attached file testcase
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
Requesting blocking, because I think this bug is the root cause of the P2/blocking1.9+ bug 411382
Flags: blocking1.9?
Based on Comment 4 we should fix this
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Attached file testcase 2
Attached file testcase 3
This one already passes.
Attached file testcase 4
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
Flags: blocking1.9+
Priority: P2 → --
fantasai, your tests seem to WFM. Do you think there's anything we're missing or is this bug WFM?
Flags: needinfo?(fantasai.bugs)
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?
Flags: needinfo?(fantasai.bugs)
You need to log in before you can comment on or make changes to this bug.