Open
Bug 381497
Opened 18 years ago
Updated 2 years ago
page area not initial containing block for print
Categories
(Core :: Printing: Output, defect)
Core
Printing: Output
Tracking
()
NEW
People
(Reporter: fantasai.bugs, Unassigned)
References
Details
(Keywords: testcase)
Attachments
(4 files)
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?
|
||
Comment 2•18 years ago
|
||
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.
|
||
Updated•17 years ago
|
Attachment #265561 -
Attachment mime type: text/xhtml+xml → application/xhtml+xml
|
||
Comment 4•17 years ago
|
||
Requesting blocking, because I think this bug is the root cause of the P2/blocking1.9+ bug 411382
Flags: blocking1.9?
|
||
Comment 5•17 years ago
|
||
Based on Comment 4 we should fix this
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
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
|
|
||
Comment 10•7 years ago
|
||
fantasai, your tests seem to WFM. Do you think there's anything we're missing or is this bug WFM?
Flags: needinfo?(fantasai.bugs)
|
Reporter | |
Comment 11•7 years ago
|
||
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)
|
||
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•