User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040812 Firefox/0.9.1+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040812 Firefox/0.9.1+ A wrapper div "contentarea" contains a float. A clearing element in contentarea after the float brings back the document flow so content area actually contains the float. The float is several printed pages worth of content. When print previewing (shrink to fit for this senario, others settings have the same effect) and/or printing, a bottom border on the contentarea displays at the bottom of page 1, when really its contents go to page 7. Content that comes after the float in the document flow will start at page 2 overlaying the floats content. See the testcase attached and do a print preview. Reproducible: Always Steps to Reproduce: 1. view testcase 2. do print preview or print the page out 3. see where the bottom border shows up at the end of page 1 4. see where the document flow content after the float shows on page 2 5. see that 7 pages print. Expected Results: It should layout correctly like the browser does. The clear element should be honored, and document flow text at the end should be below the float and clear element. The bottom border should come after the float and clear element, and before the document flow text at the end.

Possibly related to <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=216911">Bug 216911</a>?

I see this on LInux 2004091107. I did notice the Footer was after second column and I couldn't find the subfooter in the second testcase.

Attached is a simplified testcase. In Print Preview, red parent DIV does not stretch to include a blue float. Its height is as tall as the first page.

EDIT: In Print Preview, a blue DIV does not stretch to include a red float.

Not purely in previews; happens in the printout, too. (Print to a PDF on OS X, for instance.)

Testcase 1 and the Simplified Testcase pass for me on a trunk build. Testcase 2 is missing the second yellowish box for some reason...

In the latest Minefield nightly (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091014 Minefield/3.7a1pre), I concur with comment 9. It sounds like at least *part* of this bug is FIXED in 1.9.3. In my two-weeks-old Camino nightly (2.1a1pre (1.9.0.15pre 2009100200)), none of the three work properly, although the yellow box in testcase 2 isn't missing; it's misplaced at the bottom of the printout on the far left side. Using the latest release build of Firefox (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3), I see similar results to Camino. That at least narrows down the partial fix to 1.9.2 or trunk (I didn't check a Firefox 3.6 build).

test case 1 & 3 fail in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1) Gecko/20090806 Namoroka/3.6a1 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b1) Gecko/20091014 Firefox/3.6b1 (although test case 3 has a different behaviour in 3.6b1. The right & left edges of the blue box extend to the second page in 3.6b1) On trunk: fails: Gecko/20090831 Minefield/3.7a1pre http://hg.mozilla.org/mozilla-central/rev/d87974838fa9 works: Gecko/20090901 Minefield/3.7a1pre http://hg.mozilla.org/mozilla-central/rev/e3e594837a30 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d87974838fa9&tochange=e3e594837a30 That points to bug 492627 for having partially fixed this.

Thanks, Philippe. Fantasai, should a new bug be filed on testcase 2 and this one RESOLVED FIXED by bug 492627?

Yes, that sounds like a good idea to me. Please CC me on the new bug.

FIXED by bug 492627; the new bug is bug 522604 and I've reduced the testcase even further.