Closed
Bug 198513
Opened 22 years ago
Closed 16 years ago
page-break-after broken in mozilla 1.3 final (only for empty frames)
Categories
(Core :: Printing: Output, defect)
Core
Printing: Output
Tracking
()
RESOLVED
DUPLICATE
of bug 132035
People
(Reporter: dnfesp, Unassigned)
Details
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
I'm taking advantage of the printing capabilities of mozilla with its advanced
css support, but I got into a problem switching from 1.1 (and phoenix 0.5) to
1.3 final, I'm using a lot the page-break-after css rule in one of my projects,
now with the new release it seems to be broken or badly processing this rule.
I'm attaching a test case, please try it with phoenix 0.5 or a relative version
of mozilla, then try it on mozilla 1.3 final. Use print-preview to see the
difference, the content must be split up in 3 pages uniformly, 1.3 shows 2 pages
and the last one is really messed up.
Reproducible: Always
Steps to Reproduce:
Reporter | ||
Comment 1•22 years ago
|
||
Reporter | ||
Comment 2•22 years ago
|
||
This new test case illustrate even better the problem I'm refering to, this is
a confirmation of the broken page-break rule.
Reporter | ||
Comment 3•22 years ago
|
||
I can now confirm, it's broken since mozilla 1.3b
affected rules: page-break-after, page-break-before
mozilla is now unable to do page breaks (in printed media), this was correctly
implemented before and worked great, hope this bug gets fixed soon.
I'm reassigning this because has to do with printed media exclusively.
Component: Layout → Printing
Reporter | ||
Updated•22 years ago
|
Component: Printing → Layout: Block & Inline
Comment 4•22 years ago
|
||
The problem seems to be that the divs that have page-break set on them are all
0-height. If I make the middle one a different height, I get 3 pages. It used
to be, incorrectly, a nonzero height because of the position:relative style on
it, but that got fixed.
Over to printing; the height of the frames should not affect page breaking,
should it? Is something optimizing away reflow of things whose computed height
is 0 somewhere?
Assignee: other → printing
Status: UNCONFIRMED → NEW
Component: Layout: Block & Inline → Printing
Ever confirmed: true
OS: Windows 2000 → All
QA Contact: ian → sujay
Hardware: PC → All
Summary: page-break-after broken in mozilla 1.3 final → page-break-after broken in mozilla 1.3 final (only for empty frames)
Updated•16 years ago
|
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•