Last Comment Bug 294991 - Print & Print Preview truncate tables over 1 page long if there is a caption
: Print & Print Preview truncate tables over 1 page long if there is a caption
Status: RESOLVED FIXED
[reflow-refactor] PLEASE READ COMMENT...
: dataloss, regression, testcase
Product: Core
Classification: Components
Component: Layout: Tables (show other bugs)
: Trunk
: x86 All
: -- critical with 14 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://postcalc.usps.gov/Zonecharts/d...
: 301378 301711 312855 323688 324532 339854 341907 346656 369602 372461 378329 (view as bug list)
Depends on: 292124 452845
Blocks: 521204 369140
  Show dependency treegraph
 
Reported: 2005-05-20 15:30 PDT by Jonathan Sachs
Modified: 2011-08-27 11:22 PDT (History)
37 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (1.94 KB, text/html)
2005-05-20 20:18 PDT, Andrew Schultz
no flags Details
Contains <table> with <thead> and <tfoot> (3.89 KB, text/html)
2005-11-24 13:00 PST, Alex
no flags Details

Description Jonathan Sachs 2005-05-20 15:30:51 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050520 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050520 Firefox/1.0+

Enter "606" in the "3-digit ZIP CODE prefix" box and click "Get Zone Chart."
Then select File / Print Preview, or print the page. Mozilla displays/prints
three pages. The first one contains material preceding the table, the second one
contains most but not all of the table, and the third one is empty. The part of
the table that does not fit on the second page is not printed at all.

Internet Explorer does essentially the same thing, but this is incorrect
behavior for any browser.

Reproducible: Always

Steps to Reproduce:
See "Details," above.
Actual Results:  
See "Details," above.

Expected Results:  
Anything that allows all the information to print. It seems most natural to let
the table flow onto the following page (and as many subsequent pages as necessary).
Comment 1 Andrew Schultz 2005-05-20 20:18:44 PDT
Created attachment 184158 [details]
testcase

in print preview, the first page has the <input>, the second page has the
caption and some of the table.	the third page is blank (should have the rest
of the table)

tested with linux suite trunk 2005051905
Comment 2 Andrew Schultz 2005-05-20 20:28:16 PDT
this regressed between linux trunk 2005021505 and 2005021613, probably bug 274516

==> tables
Comment 3 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-06-19 23:03:49 PDT
See http://lxr.mozilla.org/mozilla/source/layout/tables/nsTableOuterFrame.cpp#2002

The problem seems to be that we reflow the inner table, *then* we reflow and
place the caption, which moves the inner table down. The inner table no longer
fits on the page so bad things happen.

It looks like we want to reflow the table first to find the table width before
we reflow the caption, but we need to reflow the caption first so we know the
available height ... I'm not sure how to resolve this circularity. Any ideas Bernd?
Comment 4 wam2 2005-11-03 15:10:54 PST
> The problem seems to be that we reflow the inner table, *then* we reflow and
> place the caption, which moves the inner table down.

It's not only about caption. Removing caption from the table often helps (as it does in the above test case) but is not a fool proof workaround. I had large tables without a caption truncated depending on the css line-height that affected the document content ahead of the table (e.g., printed fine at 140%, truncated with line-height set to 137%, in Fx1.5RC/WinXP).

This bug ruins technical papers with long tables. Too bad it will not be fixed for Fx1.5.
Comment 5 Alex 2005-11-24 11:59:50 PST
I am pretty sure this bug did not exist in 1.0.7, only the newer RCs.  Tables had printed normally, even repeating <thead> on each page as it should.  Is is possible to revert back to the old stable code?
Comment 6 Alex 2005-11-24 13:00:23 PST
Created attachment 204135 [details]
Contains <table> with <thead> and <tfoot>

The table should start on the first page and continue on the next page.  There are 50 rows in the tbody, but only 39 show.
Comment 7 Alex 2005-11-24 13:02:33 PST
This was interesting: if a table with <thead> and <tfoot> overflows the page, the table starts on a new page, clips at the end of the page, and prints the new page with only the <thead> and <tfoot>.  The overflowing content should have been shown between the <thead> and <tfoot>.  See "Contains <table> with <thead> and <tfoot>" attachment
Comment 8 :aceman 2006-05-01 08:04:10 PDT
*** Bug 312855 has been marked as a duplicate of this bug. ***
Comment 9 VerLok 2006-07-31 06:30:11 PDT
(In reply to comment #0)

From further tests, you can see that the bug happens when BOTH THE FOLLOWING
CONDITIONS are respected:

A) The page contains an <h1> title
B) The table in the page contains a <caption>

For full test case this bug, please refer to:

Page that generates the bug:

http://www.andreaverlicchi.com/bugs/mozillaprint_with_h1_and_caption.php

Pages that DON'T generate the bug:

http://www.andreaverlicchi.com/bugs/mozillaprint_with_h1.php
http://www.andreaverlicchi.com/bugs/mozillaprint_with_caption.php

I hope now it's easier to correct.
Comment 10 Alex 2006-07-31 13:47:03 PDT
Not in Firefox 2.0 Beta 1 on Windows (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060710 Firefox/2.0b1).

I think this bug is fixed and someone with more permissions than me should mark it as FIXED (after verifying my claim, of course).  If you are annoyed with it, download the beta at http://www.mozilla.org/projects/bonecho/all-beta.html or wait until the final comes out hopefully August 8
Comment 11 Marco Zanon 2006-10-14 03:20:14 PDT
Something similar happens to me (using Fx 1.5 on Linux, but also tested on 2.0RC2). On some circumstances, long tables are not printed starting in the right page, but they are moved one page down, which breaks formatting. (The same pages are rendered correctly on Opera 9.)
Comment 12 Dan Erikson 2007-03-26 12:38:39 PDT
This bug still exists on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20060601 Firefox/2.0.0.2 (Ubuntu-edgy)
Comment 13 :Mook 2007-04-21 17:59:33 PDT
*** Bug 378329 has been marked as a duplicate of this bug. ***
Comment 14 Chris Lawson (gone) 2007-06-06 21:59:43 PDT
*** Bug 372461 has been marked as a duplicate of this bug. ***
Comment 15 Jim Ronback 2007-06-07 10:29:34 PDT
Going back to the duplicate Bug 378329, this bug has not gone away using Firefox 2.0.0.4. There is another anomaly/ clue, in that, if you shrink the page down to 30% you get more text onto the first page only, but the leftmost and rightmost columns do not have their fonts shrunk as much as the middle columns. The shrinking is not uniform and it still only puts truncated text on the first page and one tiny line on the 2nd page.
Comment 16 Chris Lawson (gone) 2007-06-07 10:50:37 PDT
(In reply to comment #15)
> Going back to the duplicate Bug 378329, this bug has not gone away using
> Firefox 2.0.0.4.

No; the fact that this bug is still open is an acknowledgment that it is still not fixed.

The problem appears to be known, but a means of fixing it has not been determined. See comment 3.

Unless you are a developer actively involved in fixing this bug, commentary here is likely to be less than helpful. Please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html before commenting.

cl
Comment 17 Boris 'pi' Piwinger 2007-08-18 08:15:56 PDT
*** Bug 301711 has been marked as a duplicate of this bug. ***
Comment 18 Boris 'pi' Piwinger 2007-08-18 08:16:58 PDT
*** Bug 324532 has been marked as a duplicate of this bug. ***
Comment 19 Boris 'pi' Piwinger 2007-08-18 08:18:36 PDT
*** Bug 339854 has been marked as a duplicate of this bug. ***
Comment 20 Boris 'pi' Piwinger 2007-08-18 08:18:41 PDT
*** Bug 346656 has been marked as a duplicate of this bug. ***
Comment 21 Boris 'pi' Piwinger 2007-08-18 08:18:52 PDT
*** Bug 369602 has been marked as a duplicate of this bug. ***
Comment 22 Boris 'pi' Piwinger 2007-08-18 08:19:00 PDT
*** Bug 323688 has been marked as a duplicate of this bug. ***
Comment 23 Boris 'pi' Piwinger 2007-08-18 08:19:14 PDT
*** Bug 341907 has been marked as a duplicate of this bug. ***
Comment 24 Boris 'pi' Piwinger 2007-08-18 08:19:23 PDT
*** Bug 301378 has been marked as a duplicate of this bug. ***
Comment 25 Boris 'pi' Piwinger 2007-08-18 08:21:33 PDT
It happens on many different pages effectively making it unable to print many pages with Mozilla. So the data on the page is lost, marking accordingly.

pi
Comment 26 David E. Ross 2007-08-18 10:16:56 PDT
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4

Another example is at <http://www.oakparkfoundation.org/grant_log.html>.  
Comment 27 Bernd 2007-08-19 09:02:26 PDT
I have big difficulties to see that the dupes (comment 17 till comment 24) are valid dupes. As the white board says read comment 3 before fiddling with this bug.
Take for instance bug 301378, the test case there has no caption at all. This bug has not been a trash bin for bad table printing and should not be converted into one. Boris could you please verify that your changes are valid and revert them if the only basis for your decision has been the fact that something is truncated.
Comment 28 Michel Loiseleur 2007-11-02 07:28:26 PDT
A good sample page is here : http://development.openoffice.org/releases/2.3.0.html
You cannot print it without reducing scale to 50% and put it into landscape.
Comment 29 Eevee (Lexy Munroe) [:eevee] 2007-12-27 09:07:59 PST
Every testcase on this bug WFM on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007122605 Minefield/3.0b3pre.  The link in comment 3 is no longer valid; the file doesn't have anywhere near 2002 lines.  Was this fixed by the reflow branch?
Comment 30 Michel Loiseleur 2007-12-28 04:47:52 PST
It works for me too, with firefox 3 beta 2, on linux.
That's a really good news !
Comment 31 Jim Ronback 2007-12-28 13:09:33 PST
Why I try to print this web page with FireFox, only the first page is displayed
in Preview and only the first page is printed. On Internet Explorer after
selecting "print preview" it will print all 5 pages when 100% size is selected,
otherwise it compresses the 5 pages onto one page in IE with the default
"shrink to fit" option.
http://www2.parl.gc.ca/HousePublications/Publication.aspx?Language=E&Parl=39&Ses=1&Mode=1&Pub=Bill&Doc=C-427_1&File=24#1

Reproducible: Always

Steps to Reproduce:
It still does not work with 2.0.0.11
1.Select print icon
2.Print all selected as default
3.hit print
4. Only the first page of a 5 page document is printed
Actual Results:  
Only the first page of a 5 page document is printed. Whereas on IE 7.0.5730.11
all 5 pages are printed

Expected Results:  
I expect all 5 pages to be printed.
Comment 32 Eevee (Lexy Munroe) [:eevee] 2007-12-28 13:12:51 PST
Above page also WFM, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007122705 Minefield/3.0b3pre
Comment 33 Lucius Chiaraviglio 2008-12-05 13:58:41 PST
This bug still exists in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4; also found that Internet Explorer 7.0.5730.11CO has a similar (same?) bug (in contrast to comment #31 above), which makes me wonder if the problem is in Windows components that Firefox calls for Print/Print Preview.  Example of a page that has this problem in both browsers, and additionally won't reliably display figures in Internet Explorer (at least Firefox does that right, but then also displays capital Delta in the table as D):  http://www.pnas.org/content/103/8/2857/suppl/DC1
Comment 34 Lucius Chiaraviglio 2008-12-05 14:18:30 PST
Found that Safari 3.2.1 (525.27.1) on Windows XP prints the table correctly (except that it still messes up the Greek letters both in and out of the table).
Comment 35 David E. Ross 2008-12-06 11:00:22 PST
Re comment #33:  Using my example (comment #26), I do not see this with IE 7 (7.0.5730.11).  

Unrelated to this problem (or is it?), however, the renderings of the table in my example between Gecko (1.8.1.18) and IE 7 differ.  Gecko shows only horizontal lines between table rows (the intended rendering) while IE also shows vertical lines on the edges of the table.  This difference is also seen in what is printed.
Comment 36 David E. Ross 2010-10-14 08:56:42 PDT
Someone else is now the Web master for the Community Foundation for Oak Park.  Contrary to the best practices for foundations, the Web site no longer contains a list of grants issued.  Thus, my comment #26 is no longer valid.
Comment 37 David E. Ross 2010-10-14 15:53:15 PDT
I retrieved the Web page cited in comment #26 from my archives and set it up as <http://rossde.com/test/large_tables.html>.
Comment 38 Jim Ronback 2011-04-14 12:03:46 PDT
(In reply to comment #15)
> Going back to the duplicate Bug 378329, this bug has not gone away using
> Firefox 2.0.0.4. There is another anomaly/ clue, in that, if you shrink the
> page down to 30% you get more text onto the first page only, but the leftmost
> and rightmost columns do not have their fonts shrunk as much as the middle
> columns. The shrinking is not uniform and it still only puts truncated text on
> the first page and one tiny line on the 2nd page.

The problem described in comment #15 has disappeared with FireFox version 4.0. Although I can now print all 5 pages I still have to reduce the size to 90% to avoid truncating the notes in the margin on the right hand side.
Comment 39 Jim Ronback 2011-04-14 12:09:00 PDT
The problem described in comment #31 has also disappeared with FireFox version 4.0. Although I can now print all 5 pages I still have to reduce the size to 90% to avoid truncating the notes in the margin on the right hand side.
Maybe this bug can be closed.
Comment 40 Dirk Schoettler 2011-04-16 08:10:35 PDT
One more example for truncating after page 1.
http://www.norfolkline.com/EN/Blank/Terms/

It happens with Firefox 3.6 and 4.0.
Comment 41 :aceman 2011-04-16 08:36:10 PDT
Can confirm on Linux, also with FF 5.0a2 (aurora). However, that page does not use a table. It contains the whole page in a strange <span style="display: inline-block">.
Comment 42 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2011-04-16 09:07:00 PDT
Then that's bug 534182 rather than this bug.
Comment 43 Dirk Schoettler 2011-04-16 14:08:40 PDT
Thank you, aceman/dbaron, I posted it there.
Comment 44 Bernd 2011-08-07 22:58:01 PDT
I believe this has been fixed by bug 642088 on trunk
Comment 45 :aceman 2011-08-08 10:20:00 PDT
Can confirm that on
Mozilla/5.0 (X11; Linux i686; rv:8.0a1) Gecko/20110804 Firefox/8.0a1 ID:20110804030732
the table does no longer start always at page 2, but it starts to draw where there is space on page 1. I haven't noticed any truncated content. I think this was the problem description in comment 0 (URL no longer works) and comment 6.
I checked this on links in comment 33 and comment 37. Can't see any difference in comment 31. I have compared FF 5 to the build mentioned above. There are still other problems with table printing, but this one seems to have changed somewhat. The respective commenters should check their testcases.
Comment 46 Jim Ronback 2011-08-09 20:38:35 PDT
The problem in comment #31 is fixed. I can print all the text only if the size is reduced to about 90% which results in 5 pages. If autofit to page width is selected the rightmost column gets truncated. So a new (?) problem still exits
Comment 47 Bernd 2011-08-23 11:50:34 PDT
comment #31 is not relevant to this bug as does not contain a caption. fixed by bug 642088
Comment 48 David E. Ross 2011-08-24 11:11:37 PDT
In which Gecko version is this fixed?
Comment 49 Bernd 2011-08-24 22:22:51 PDT
any build that contains http://hg.mozilla.org/mozilla-central/rev/2676a94cee76
Comment 50 :aceman 2011-08-25 00:09:55 PDT
(In reply to David E. Ross from comment #48)
> In which Gecko version is this fixed?

According to bug 642088, it is in Firefox 8, which is in Aurora now.
Comment 51 David E. Ross 2011-08-27 10:44:05 PDT
For the benefit of end-users who follow bug reports, it would be nice if such reports were NOT marked as Fixed until the release containing the fix were pending within only a day or two.  Perhaps a new Bugzilla status of Pending would be appropriate.
Comment 52 Bernd 2011-08-27 11:22:55 PDT
Can you please advocate you ideas not in a bug but in a news group (see https://bugzilla.mozilla.org/page.cgi?id=etiquette.html point 1 "Constructive and helpful thoughts unrelated to the topic of the bug should go in the appropriate newsgroup.",  we have have done this this way as long as I am aware off (aka since 2000).

Note You need to log in before you can comment on or make changes to this bug.