User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040114 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040114 Whenever I attempt to print or print preview http://www.mount.com/direction.html I get over 160 pages of output. The map is converted into many pages of very short strips. I have a Postscript level 2 printer. Reproducible: Always Steps to Reproduce: 1. Go to http://www.mount.com/direction.html 2. Click print preview 3. Look at the bad output

Confirmed on Linux build 2004012207 OS/2 build 2004012108 works fine

Is this a problem with the interlaced image painting all wrong somehow? Do other interlaced images fails too?

The problem happens on linux, win32, and os/2 (though oddly much less severe on the latter). Quite a few assertions of the form: ###!!! ASSERTION: aContent1 must not be null: 'aContent1', file /home/tor/src/mozilla/layout/base/src/nsLayoutUtils.cpp, line 222 Break: at file /home/tor/src/mozilla/layout/base/src/nsLayoutUtils.cpp, line 222 ###!!! ASSERTION: aContent2 must not be null: 'aContent2', file /home/tor/src/mozilla/layout/base/src/nsLayoutUtils.cpp, line 223 Break: at file /home/tor/src/mozilla/layout/base/src/nsLayoutUtils.cpp, line 223 Layout issue?

I can reproduce the effect on solaris using a cvs build from 2004/01/14 and an old nightly from 2003/09/14. I don't think this is specifically related to the image; mozilla is just rendering the bottom half of the page in little strips for some reason. The original page contains several paragraphs of text following the image (directions to the office). When printing the page, the last several pages of the printout contain no content other than this text, at one line per page. I saved the html for the page to a local file and loaded it into mozilla. All of the images were broken, but printing this page still yielded a 160-page print job with one line of text per page toward the end. I've reduced this page to something just containing the directions; viewed in print preview it still yields 20-odd pages with one line of text per page.

OS/2 build has no problem with the testcase. Just 1 page as expected.

Hmm.. In the reduced testcase the problem is that the table cell should be 1087 pixels tall and that this is too big to fit on a page, and then something gets confused in the mess that is the splitting code...

In the original sample page, the <img> for the map is contained within the same <td> block as the text, and the <td> is contained within a <tr> with a height="3" attribute. When printing the sample page, the image slivers were mostly 3 pixels high. Here I've restored the <img> tag to the <td> section containing the text, and added a height="10" attribute to the containing <tr>. Print preview yields a 63-page document; the first 47 pages contain 10-pixel slivers of the image; the rest contain a line or so of text. Changing the value of the height attribute in the first <tr> changes the height of the slivers; if the height is tall enough, mozilla will also put more than one line of text on the text pages. If the height attribute on the first <tr> is removed, I get a 392-page print job where the image slivers are one pixel high.

Oh, hmm... So we're putting the height of the image that fits in the first row on the page, then the second row does not fit, so we page-break and try again on the next page, huh?

See bug 228584 for a more complex example.

Bug 231212 looks like another duplicate.

I can't reproduce with Linux+PostScript with either testcase with either print or print preview. (I think I tried all 4 combinations, although I may have only done 3.)

Using CVS builds from 20040309, I can still reproduce the problem reliably with either testcase. I've tried building mozilla on linux with gtk, gtk2, and xlib, and without freetype and xft; all of them behave the same. Each of the testcases contains an empty <tr> of height 1087. The bug apparently depends on this <tr> being too large to fit on the same page with the content. Making this height smaller, or selecting a larger paper size, makes the problem disappear. If you're having trouble reproducing this, you could try selecting a smaller paper size, or downloading a testcase and editing it to make the height larger.

Yeah, I can reproduce by changing 1087 to 1587.

The problem is here: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/html/table/src/nsTableRowGroupFrame.cpp&rev=3.319&mark=1150#1147 Now I'll do CVS archaeology to figure out what this was supposed to do...

The problematic code was introduced in bug 165772 (although deCOMtaminated later). Setting availHeight to something like that is clearly wrong -- availHeight should (for printing) always be a distance from the current position to the bottom of the page (for non-printing cases, it should always be NS_UNCONSTRAINEDSIZE).

This patch makes sense to me, and fixes the bug. I'm not sure how to regression-test it...

print regression tests did work with viewer -Prt 1 see http://lxr.mozilla.org/seamonkey/source/layout/html/tests/table/printing/rtest.bat on windows. They get however every now and then broken by somebody who doesnt understand the sense of the file argument or some stupid dialog that pops up. I can run them for you, and attach a hack that I used to get them running again. In principle it would be cool to have these print regression tests attached to the layout debugger. I remember that you told me that these tests never worked on linux. I will need some time for the review, as I did avoid the printing code up to now.

Comment on attachment 145770 [details] [diff] [review] patch I runned the rtest.bat in table/printing and did not see a regression test failure.

Comment on attachment 145770 [details] [diff] [review] patch a=asa (on behalf of drivers) for checkin to 1.7

Fix checked in to trunk, 2004-04-13 13:47:52 -0700. Fix checked in to MOZILLA_1_7_BRANCH 2004-04-16 14:21:09 -0700.

verified