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.
I also see the bug with the latest nightly build.
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → Trunk
Assignee: nobody → printing
Status: UNCONFIRMED → NEW
Component: Layout → Printing
Ever confirmed: true
QA Contact: layout
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.
*** Bug 283501 has been marked as a duplicate of this bug. ***
Also see bug 301711: 1.5RC3 still doesn't print tables well.
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
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 294991
You need to log in before you can comment on or make changes to this bug.