User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0 Build ID: 20121128204232 Steps to reproduce: 1. copy the following code into an html file: <div style="border: 1px solid #000; max-height: 8cm; max-width: 8cm; font-size: 48pt; overflow: hidden;">1<br />2<br />3<br />4<br />5<br />6<br />7<br />8<br />9</div> 2. open the file in Firefox (a box with the digits 1-4 should be shown) 3. show the print-preview of the page 4. use a custom paper format (tested with 4"x8", landscape) 5. a) max-height, 100% scale-size (in print-preview) b) max-height, 50% scale-size (in print-preview) c) height, 100% scale-size (in print-preview) Actual results: a) The numbers 1-9 are shown. They are spread over three pages (1-4, 5-8, 9), bordered by a black line. b) Just like in the browser view, the numbers 1-4 are shown in print-preview. They fill half the page/less than half the page. c) Just like in the browser view, the numbers 1-4 are shown in print-preview. They fill the complete page. Using the CSS-property "height" instead of "max-height" is possible. Expected results: Just like in the browser view the numbers 1-4 are shown in print-preview, no matter if you use "max-height" or (static) "height".

I can reproduce this with F10, so not a recent regression.

Old regression indeed. ;) m-c good=2010-10-06 bad=2012-10-07 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dee1e01fd8ed&tochange=5bb4f093a50b Boris Zbarsky — Bug 129941. Don't create scrollframes for blockframes (except inline blocks) while printing, and make such blockframes clip their contents instead. r=dbaron

I can't reproduce w/ the attached testcase, **but** I can reproduce if I increase font-size to 90pt. (I think it only reproduces if there's enough text to overflow the first page, and on my system (due to fonts or whatever), I have to increase the font-size to make that happen) So: this affects trunk, Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20121213 Firefox/20.0

Here's a more robust testcase (w/ more content). It's got a numbered list w/ 200 entries, in an "overflow:hidden" div. Only the topmost 4 inches should be visible (entries 1 - 19, on my system), but in print-preview, the max-height appears to be ignored, and we print all 200 entries.

That's odd. I would have expected max-height to Just Work in the new setup... I can confirm that this works correctly as long as the total height of the text is smaller than a page, but that as soon as it gets bigger than a page things go awry. Presumably something about blockframe splitting and how it handles max-height is responsible. Is it possible to reproduce this in columns too?

Here's a reference case for testcase 2 -- I've just replaced "max-height" with "height", and that fixes it.

(In reply to Boris Zbarsky (:bz) from comment #6) > Is it possible to reproduce this in columns too? Doesn't look like it, w/ this testcase.

On Win 7, I just selected paper format A6 instead of A4 (default) in the Microsoft XPS Writer. With A6, in landscape mode (more visible), numbers 5 to 9 are displayed in preview/output print.

I suspect the problem is this line in nsBlockFrame: nscoord autoHeight = aReflowState.ApplyMinMaxHeight(contentHeight); It needs to subtract out the height consumed by prev-in-flows. Scott's patch in 743402 sets up infrastructure to make this easy and fixes the corresponding problem for nsColumnSetFrame; it just also needs to update this call to pass in consumedHeight for nsBlockFrame as well.