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).

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

this regressed between linux trunk 2005021505 and 2005021613, probably bug 274516 ==> tables

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?

> 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.

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?

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.

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

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

(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.

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

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.)

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)

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.

(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

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

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>.

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.

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.

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?

It works for me too, with firefox 3 beta 2, on linux. That's a really good news !

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.

Above page also WFM, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007122705 Minefield/3.0b3pre

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

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).

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.

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.

I retrieved the Web page cited in comment #26 from my archives and set it up as <http://rossde.com/test/large_tables.html>.

(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.

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.

One more example for truncating after page 1. http://www.norfolkline.com/EN/Blank/Terms/ It happens with Firefox 3.6 and 4.0.

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">.

Then that's bug 534182 rather than this bug.

Thank you, aceman/dbaron, I posted it there.

I believe this has been fixed by bug 642088 on trunk

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.

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 #31 is not relevant to this bug as does not contain a caption. fixed by bug 642088

In which Gecko version is this fixed?

any build that contains http://hg.mozilla.org/mozilla-central/rev/2676a94cee76

(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.

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.

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).