301378 - Tables with large rowspan cells cause blank pages in printouts and incomplete table printing

Status: RESOLVED DUPLICATE of bug 294991

(Core :: Printing: Output, defect)

Description

[Fredrick Knieper]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9) Gecko/20050711 Firefox/1.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9) Gecko/20050711 Firefox/1.0.5

When printing a table that uses <td rowspan=X>contents</td>, if X rows of the
table cannot fit on the current page, firefox apparently drops some rows on the
page so far (creating a blank or mostly blank page and simply losing table data
from before that point), then drops the first row of data containing the
rowspan, then prints the remaining rows of the table (without the td rowspan...
you can see based on how the borders are drawn that this element was removed
entirely) until the next rowspan cell, where the process repeats with more rows
lost at the next rowspan cell.  This occurs both when printing to paper and when
using print preview.

Reproducible: Always

Steps to Reproduce:
1. View a website with a large table using rowspan attribute
2. Print the website or use Print Preview
3.

Actual Results:  
Everything after the first line on the piece of paper, up to the row of the
table including the <td rowspan> element is not printed.

Expected Results:  
Printed the entire table.

This is also reproduced on Mozilla
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414
and Deer Park Alpha 1.

On the test URL provided, There are 7 rows of "Stuff" before the first <td
rowspan>.  Only the first row of Stuff is printed, there is then blank space, a
single <td> top border floating in the middle of the page, then the rest of the
page is blank.  Regardless of how much "Stuff" I insert there, only the first
row of the table on that page will print.  On the next page, printing starts
again from "Line 2" of "Section 1".  The blanking is not done by table cell
boundary: by my font settings the sample page has a pagebreak after "Junk Data
29" and only the first line of "Junk Data 28" is displayed, with a pagebreak
below that.

Zooming the print preview to 175% or greater, or shrinking to 30% or less causes
more of the table to print, however some cells are still either not completely
displayed or lost entirely ("Section 2" simply prints "2" on a line of its own).

Font settings are Serif/Times New Roman/Arial at 16 pixels and 96dpi display.

Comment 1

[Fredrick Knieper]

Attachment: Test case which is described in the bug

Comment 2

[Martijn Wargers (dead)]

I also see the bug with the latest nightly build.

Comment 3

[Fredrick Knieper]

Confirming this on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8)
Gecko/20050513 Debian/1.7.8-1

Looks like it's platform and printer independent.  Interesting thing I noticed
here, the print preview does not scroll using the mousewheel if the mouse is
over the blanked-out portion of the "paper".  If I move the mouse to the side
off the paper, or point to a part of the paper where the table is being printed
normally, or use the keyboard to scroll, I can scroll the screen.

Comment 4

[dolphinling]

*** Bug 283501 has been marked as a duplicate of this bug. ***

Comment 5

[Julian D. A. Wiseman]

Also see bug 301711: 1.5RC3 still doesn't print tables well. 

Comment 6

[Boris 'pi' Piwinger]

There are many similar bug reports and in fact the bug is as old as I can think about it. Essentially, some table data is lost when printing. Duping this to a bug which is rather general. If you are sure that it is different, please undo.

pi