649802 - Abspos with margin gets progressively skinnier on each printed page

Status: RESOLVED DUPLICATE of bug 563436

(Core :: Printing: Output, defect)

Description

[David Bourguignon]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0

The print function of Firefox 4.0 has sometimes a strange behavior. (I am in fact always printing to PDF files, using currently PDFCreator 1.2, latest.) It works quite well on most pages I have seen, but not very well on a very simple, valid XHTML test page... I have checked with Opera 11.0, latest, and it works perfectly, therefore the problem comes most probably from Firefox 4.0.

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.davidbourguignon.net/texts/critique-du-film-home-de-yann-arthus-bertrand.html
2. Click on the menu File > Print > Print to PDF (when PDFCreator 1.2 is installed as PDF printer)
3. Look at the resulting PDF : page 1 is roughly OK, page 2 and over are completely wrong...
4. Compare the output of the print to PDF manœuver on Opera 11: it works perfectly.
Actual Results:  
Wrong PDF output. (See file pdfcreator1.2-firefox4.pdf in attachment.)

Expected Results:  
Correct PDF output. (See file pdfcreator1.2-opera11.pdf in attachment.)

It seems that similar bugs have been reported in the past... (See bug 384841 for example.) I will try to attach the mentioned PDFs for clarity of the demonstration.

Comment 1

[David Bourguignon]

Attachment: Wrong PDF output

Comment 2

[David Bourguignon]

Attachment: Correct PDF output

Comment 3

[Tim (fmdeveloper)]

Does the page appear correctly in print preview?

Comment 4

[David Bourguignon]

Thanks Tim for your quick reply. Nope, I just checked: the page looks exactly the same in the print preview as in the PDF...

Comment 5

[Tim (fmdeveloper)]

The same issue occurs in 3.6

Changing the following css rule:

div.texts-body {
    font-family: "Trebuchet MS",Helvetica,sans-serif;
    margin-left: 20%;
    margin-right: 20%;
    margin-top: 300px;
    position: absolute;

to

div.texts-body {
    font-family: "Trebuchet MS",Helvetica,sans-serif;
    margin-top: 300px;
    position: absolute;

resolves the issue.

Comment 6

[David Bourguignon]

Alright Tim, but this is no longer my original layout! :-)

The CSS I'm using is fully valid according to W3C validator. Yes, the issue was also there in Firefox 3.6. It's part of the lingering printing problems that have never been addressed apparently. (There are many bug reports about that, I mentioned bug 384841 for example.)

Does this mean that Mozilla does not intend to implement fully the CSS specifications for printing HTML pages from Firefox?

Thanks in advance for your help!

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to comment #6)
> Alright Tim, but this is no longer my original layout! :-)
> The CSS I'm using is fully valid according to W3C validator.
[etc]

I don't think Tim was suggesting "Change your site to this and the problem will be fixed."  I think he was just offering some insight into what's going on, for the purpose of helping to get to the root of the problem in Firefox.

> Does this mean that Mozilla does not intend to implement fully the CSS
> specifications for printing HTML pages from Firefox?

Hopefully the above addresses this loaded question, too. :)

Comment 8

[David Bourguignon]

Thanks Daniel for the explanation. I should have been more careful in replying to Tim's answer... Sorry for this mishap. Thanks in advance for your help guys!

Comment 9

[Tim (fmdeveloper)]

Still an issue on Mozilla/5.0 (Windows NT 5.1; rv:9.0a1) Gecko/20110903 Firefox/9.0a1 ID:20110903030832

Comment 10

[Daniel Holbert [:dholbert]]

(clarifying bug summary)

I believe I've seen another similar open bug, but I don't know the bug number offhand.  Flagging as possible-duplicate.

Comment 11

[fantasai]

Attachment: testcase

Comment 12

[fantasai]

Seems to me the affected cases (this bug, and bug 1033149) are all related to overflow containers.
And I'm guessing the bug is here:

https://dxr.mozilla.org/mozilla-central/rev/b5a3b8ef6902998507fc881b6d628b055457fe31/layout/generic/nsContainerFrame.cpp#1171
      nsSize containerSize = aReflowInput.AvailableSize(wm).GetPhysicalSize(wm);
      LogicalRect prevRect = prevInFlow->GetLogicalRect(wm, containerSize);

      // Initialize reflow params
      LogicalSize availSpace(wm, prevRect.ISize(wm),
                             aReflowInput.AvailableSize(wm).BSize(wm));

Afaict, we're passing in the frame's intended width as its available space; which works only if there's no margin. If there's a margin, it'll accumulate page by page exactly as we're seeing here. (What's *intended* to happen is that the frame gets the same width calculation as its prev-in-flow. I'm not 100% sure what would be the correct way to make that happen for all layout types, but this method obviously isn't it.)

Comment 14

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

This bug is fixed by bug 563436. Tested on Nightly 125.0a1 (2024-03-15).