Closed Bug 577450 Opened 16 years ago Closed 15 years ago

inherited style doesn't affect content in "position:fixed" div beyond the first page

Categories

(Core :: Printing: Output, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla2.0b10
Tracking Status
blocking2.0 --- -

People

(Reporter: gaz_millenium, Assigned: bzbarsky)

References

Details

Attachments

(6 files, 1 obsolete file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 In the case of the page with large content, we have two or more pages in print preview. We can create custom page headers on each pages by the following code: <div class="DivPrintingHeader"> center<br />center<br />center<br /> </div> ...and following style: <style media="print"> body { font-size: 80%; } #DivPrintingHeader { display: block; position: fixed; top: 0px; left: 0px; .width: 100%; } </style> in this case, body { font-size: 80%; } has effect only to custom header of first page and on the other pages custom headers have 100% font-size Reproducible: Always Steps to Reproduce: 1. Open page with necessary HTML code 2. File -> Print Preview 3. Compare font-size of content inside div on first and other pages Actual Results: font-size of content inside div on first and other pages is different Expected Results: font-size of content inside div on first and other pages have to be the same
Having the same problem on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Ubuntu/10.10 (maverick) Firefox/3.6.12 - The footer is styled with position: fixed; right: 0; bottom: 0; font-size: 0.7em; text-align: right; All of these are respected on the first page, but on subsequent pages the font-size option is seemingly ignored. Attaching example file generated with https://github.com/l0b0/worktime
Confirming. Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101202 Firefox/4.0b8pre
Status: UNCONFIRMED → NEW
Component: General → Printing: Output
Ever confirmed: true
OS: Windows 7 → All
Product: Firefox → Core
QA Contact: general → printing
Hardware: x86 → All
Summary: body {font-size: 80%;} have no effect to font inside <div> with parameters {display: block; position: fixed;} in print preview mode → body style doesn't affect content in "position:fixed" div beyond the first page
Version: unspecified → Trunk
Attached file reduced testcase 1 —
Here's a reduced testcase with 'font-style: italic' on the text, too, to show that it's not just sizing that's affected. (In my trunk nightly, the fixed-position div is only small & italic on the first page -- it is not italic & has a larger (default) size on each subsequent page)
This is broken at least as far back as Firefox 3.5 (using my reduced testcase), so this isn't a recent regression.
Here's a second reduced testcase, with the inherited style on a <div> instead of <body>. This shows that it's just a general problem with inheritance, and isn't <body>-specific. (FWIW, I tried putting the style on the <html> element, too, with the same results.)
Summary: body style doesn't affect content in "position:fixed" div beyond the first page → inherited style doesn't affect content in "position:fixed" div beyond the first page
Attachment #494771 - Attachment mime type: application/xml+xhtml → text/html
The problem is that the nsCSSFrameConstructor::ReplicateFixedFrames hack passes the canvas frame as the parent frame for the things its replicating. And we use the parent frame to determine the parent style context. Is there a reason not to inline ConstructFrame into ReplicateFixedFrames, then change the parent frame passed to AddFrameConstructionItems to be the parent frame of the placeholder of the original fixed-pos element, which is what we need to be using for style resolution?
Attachment #494931 - Attachment is obsolete: true
Assignee: nobody → bzbarsky
Whiteboard: [need review]
Priority: -- → P1
Attachment #494935 - Flags: approval2.0?
Whiteboard: [need review] → [need approval]
blocking2.0: --- → ?
Whiteboard: [need approval] → [need landing]
Flags: in-testsuite+
Whiteboard: [need landing]
Target Milestone: --- → mozilla2.0b10
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Depends on: 675246
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: