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)
Core
Printing: Output
Tracking
()
RESOLVED
FIXED
mozilla2.0b10
| Tracking | Status | |
|---|---|---|
| blocking2.0 | --- | - |
People
(Reporter: gaz_millenium, Assigned: bzbarsky)
References
Details
Attachments
(6 files, 1 obsolete file)
|
3.75 KB,
text/html
|
Details | |
|
20.72 KB,
text/html
|
Details | |
|
108.78 KB,
application/pdf
|
Details | |
|
229 bytes,
text/html
|
Details | |
|
248 bytes,
text/html
|
Details | |
|
4.09 KB,
patch
|
roc
:
review+
roc
:
approval2.0+
|
Details | Diff | Splinter Review |
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
| Reporter | ||
Comment 1•16 years ago
|
||
Comment 2•15 years ago
|
||
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
Comment 3•15 years ago
|
||
Comment 4•15 years ago
|
||
Comment 5•15 years ago
|
||
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
Comment 6•15 years ago
|
||
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)
Comment 7•15 years ago
|
||
This is broken at least as far back as Firefox 3.5 (using my reduced testcase), so this isn't a recent regression.
Comment 8•15 years ago
|
||
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.)
Updated•15 years ago
|
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
Updated•15 years ago
|
Attachment #494771 -
Attachment mime type: application/xml+xhtml → text/html
| Assignee | ||
Comment 9•15 years ago
|
||
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?
| Assignee | ||
Comment 10•15 years ago
|
||
| Assignee | ||
Updated•15 years ago
|
Attachment #494931 -
Attachment is obsolete: true
| Assignee | ||
Comment 11•15 years ago
|
||
Attachment #494935 -
Flags: review?(roc)
| Assignee | ||
Updated•15 years ago
|
Assignee: nobody → bzbarsky
Whiteboard: [need review]
| Assignee | ||
Updated•15 years ago
|
Priority: -- → P1
Attachment #494935 -
Flags: review?(roc) → review+
| Assignee | ||
Updated•15 years ago
|
Attachment #494935 -
Flags: approval2.0?
| Assignee | ||
Updated•15 years ago
|
Whiteboard: [need review] → [need approval]
| Assignee | ||
Updated•15 years ago
|
blocking2.0: --- → ?
Attachment #494935 -
Flags: approval2.0? → approval2.0+
blocking2.0: ? → -
| Assignee | ||
Updated•15 years ago
|
Whiteboard: [need approval] → [need landing]
| Assignee | ||
Comment 12•15 years ago
|
||
Flags: in-testsuite+
Whiteboard: [need landing]
Target Milestone: --- → mozilla2.0b10
| Assignee | ||
Updated•15 years ago
|
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•