379468 - Printing from monster.ca leaves output on separate pages, and cut off.

Status: RESOLVED WORKSFORME

(Core :: Layout: Tables, defect)

Description

[B. Switzer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

Go to monster.ca (or monster.com?). Get a list of jobs, any jobs, where the list spans more than one printed page. [I noticed the problem first when using the 'detail' view, but also happens with 'list' view. 'Views' being a monster.ca selection.]

Print in Internet Explorer, and all works as expected.

Print in Firefox, and the first page is the (presumably hidden) menu, the second page is the first page of the job list, and the third page is the end of the web page. While page 2 on its own is what's desired, it should continue for as many pages as necessary to print the detailed list. It stops after a single page.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[B. Switzer]

P.S. You can see what I mean in Print Preview.

Comment 2

[Mats Palmgren (inactive)]

Works for me, Firefox 2.0.0.3 on Linux.

Does the problem occur also in Firefox 3.0a4?
http://releases.mozilla.org/pub/mozilla.org/firefox/releases/granparadiso/alpha4/win32/en-US/

Comment 3

[Eli Friedman]

Attachment: testcase 1

Comment 4

[Eli Friedman]

I'm not really sure what the issue is here; it looks like the table cell isn't getting positioned correctly, though.  Any ideas, bernd?

Comment 6

[Stuart Parmenter]

dholbert: take a look at this and see if it is critical and if so renominate

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: testcase 2

Similar to first testcase, but with no JS, and with a border on the internal table so you can see it & its effects.

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to comment #6)
> dholbert: take a look at this and see if it is critical and if so renominate

I think this is critical enough to block.  I'd say it should be at least a P3 blocker.  Pretty sure it's a table-layout bug, though, so I'm relocating it to that module.

We hit this assertion during Print Preview of both testcases:

###!!! ASSERTION: data loss - incomplete row needed more height than available, on top of page: 'rowMetrics.height <= rowReflowState.availableHeight', file /mozilla/layout/tables/nsTableRowGroupFrame.cpp, line 1128

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 print-prev frametree

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 print-prev frametree

Comment 11

[Daniel Holbert [:dholbert]]

From looking at testcase 2's print-preview frametree, a few things jump out as broken:

 - The first page's first cell's "Block(td) frame" has a y-position of 35212 within its cell, which is why all the text on the first page is shifted down.

 - The first page is 58936 app-units tall, yet the first page's nested table is 122520 app-units tall  (presumably because the "height: 100%" gives it the full height of the original page-spanning outer table)
 
 - As I just stated, the first page's nested table is 122520 app-units tall, HOWEVER we were smart enough to realize that its inner cell shouldn't be that tall -- it's only 51696 app-units tall. (This can be seen visually by looking at a print-preview of testcase 2 -- the nested table's skinny cell ends on the first page, but its border-region extends off the page)

Comment 12

[Daniel Holbert [:dholbert]]

(In reply to comment #11)
>  - The first page's first cell's "Block(td) frame" has a y-position of 35212
> within its cell, which is why all the text on the first page is shifted down.

Just to elaborate on this point slightly -- we *are* making that cell the correct height in order for its contents to be able to fit on the first page.  However, this becomes broken when we shift the contents down to y=35212 within the cell -- that pushes the text off the page.

Comment 13

[Damon Sicore (:damons)]

Moving this back on to the blocking list (was wanted-next) per conversation w/ dholbert.

+'ing w/ P2.

Comment 14

[Bernd]

Attachment: reflow log

Comment 15

[Bernd]

> presumably because the "height: 100%" gives it the full height of the original page-spanning outer table

welcome to the nasty world of special height reflow and its siblings....

Comment 16

[Bernd]

we adapt the cell height at http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/tables/nsTableCellFrame.cpp&rev=3.409&mark=837-843#831

Please don't ask me what this is supposed to do.... see bug 111028 for the glory details.

Comment 17

[Bernd]

Daniel, looking at other browsers, why on earth do we have the inner table so high. No other browser does that. I think cutting the height there will certainly help with pagination.

Comment 18

[Bernd]

Just for reference the last comment is related to bug 359481

Comment 19

[Bernd]

Attachment: hack to get a discussion with daniel

Comment 20

[Daniel Holbert [:dholbert]]

Attachment: testcase 3: no percent heights

This testcase shows that this bug doesn't depend on percent-heights -- a large specified height on the inner table will trigger it as well.

Comment 21

[Daniel Holbert [:dholbert]]

Attachment: reference 3 (using inner div instead of table)

This reference case is the same as testcase 3, except that it uses a tall nested div instead of a table.  It doesn't show the bug.  (no numbers are missing in print-prev)

Comment 22

[Bernd]

this will also cause a special height reflow http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/tables/nsTableFrame.cpp&rev=3.715&mark=1869#1850

Comment 23

[Daniel Holbert [:dholbert]]

Attachment: testcase 4 (inner table tall because of contents; not broken)

Just for comparison, here's another testcase with no specified height on the inner table, but with lots of linebreaks instead, so that it's tall because of its *contents*.

Interestingly, this testcase is *not* broken.
(This makes sense, based on the code link Bernd just provided, which checks tableSpecifiedHeight).

Comment 24

[Bernd]

I looked at this with a old seamonkey Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060404 SeaMonkey/1.0.1 and it also showed a broken pagination are we really sure that this ever worked?

Comment 25

[Daniel Holbert [:dholbert]]

As mentioned in Comment 0, FF2 also has this bug.

Removing "regression" from keywords -- I think I was mistaken to put it in there.

Comment 26

[Damon Sicore (:damons)]

-'ing this per discussion with dholbert.  Not a regression from Fx2.  Doesn't mean patch will not be accepted.

Comment 27

[Daniel Holbert [:dholbert]]

Unassigning myself, as this isn't a blocker, so that someone else can pick it up if they like. :)

Comment 28

[Bernd]

All test cases are wfm, Daniel please reopen if this is still an issue