1406163 - Printing table-in-td, content invisible after first line on page 2, following page-break-after

Status: RESOLVED WORKSFORME

(Core :: Printing: Output, defect, P3)

Description

[jscher2000]

Attachment: unprintable-min.html

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170926190823

Steps to reproduce:

Document contains tables separated by a page break (test case attached). Each table contains an embedded table with no intervening elements (td > table).


Actual results:

In Firefox 56 and in Nightly, there has been a regression: The table prints correctly on page 1. On pages 2+, it is correctly sized but content after the first line is invisible. On page 3, with border-top:1px on the embedded table, all of the cell content is visible, suggesting a border collapsing problem.



Expected results:

Firefox 56 should print all of the content visibly as it did in previous versions.

SuMo thread: https://support.mozilla.org/questions/1178162

Comment 1

[Alice0775 White]

[Tracking Requested - why for this release]:Bug 1308876 causes several print regression.

I can reproduce the problem on Windows10 Nightly58.0a1.

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e6e712904806da25a9c8f48ea4533abe7c6ea8f4&tochange=d6bf703c5deaf1e328babd03d5e68ff2a4ffe10e

Via local build,
Last good: 395b6c53e42b
First bad: 1e3130e96f03

Regressed by: Bug 1308876

@:dbaron
Your bunch of patch seems to cause the problem. Can you look at this?

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

FYI -- I'm aware that a bunch of regressions from bug 1308876 turned up after it hit release (after none were reported while it was on nightly or beta).  See https://bugzilla.mozilla.org/show_bug.cgi?id=1308876#a30998038_3881 and below.  I'm going to try to look into them over the next week or two -- and hopefully there are fewer underlying problems than there are bug reports -- but these can be somewhat difficult bugs, so it might take a little time.

Comment 3

[Marcia Knous [:marcia]]

Tracking 58+ for this printing regression.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This is not fixed by bug 1474771, so it needs further investigation.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I just took a look at this. The basic problem is that a bunch of content is being left on the overflow lists of the blocks wrapping the contents of two table cells.

The process of exiting reflow, at the time we put the content on the overflow list, from the second such block, looks like this:

                   block 0x7fe6d4817228 Reflow d=21283,1 status=[Complete=N,NIF=Y,Truncated=N,Break=N,FirstLetter=N]
                  cell 0x7fe6d4817168 Reflow d=21403,121 status=[Complete=N,NIF=Y,Truncated=Y,Break=N,FirstLetter=N]
                 row 0x7fe6d4816cd0 Reflow d=38440,1320 status=[Complete=N,NIF=N,Truncated=Y,Break=N,FirstLetter=N]
                rowG 0x7fe6d4816c28 Reflow d=38440,5640 status=[Complete=Y,NIF=N,Truncated=Y,Break=N,FirstLetter=N]
               tbl 0x7fe6d4816ae8 Reflow d=38840,6040 status=[Complete=Y,NIF=N,Truncated=Y,Break=N,FirstLetter=N]
              tblW 0x7fe6d4816a40 Reflow d=38840,6040 status=[Complete=Y,NIF=N,Truncated=Y,Break=N,FirstLetter=N]
             block 0x7fe6d4816980 Reflow d=38840,6040 status=[Complete=Y,NIF=N,Truncated=Y,Break=N,FirstLetter=N]
            cell 0x7fe6d48168c0 Reflow d=38960,6160 status=[Complete=Y,NIF=N,Truncated=Y,Break=N,FirstLetter=N]
           row 0x7fe6d4816800 Reflow d=38960,6160 status=[Complete=Y,NIF=N,Truncated=Y,Break=N,FirstLetter=N]
          rowG 0x7fe6d4816758 Reflow d=38960,6160 status=[Complete=Y,NIF=N,Truncated=Y,Break=N,FirstLetter=N]
         tbl 0x7fe6d4816618 Reflow d=39360,6560 status=[Complete=Y,NIF=N,Truncated=Y,Break=N,FirstLetter=N]
        tblW 0x7fe6d4816570 Reflow d=39360,6560 status=[Complete=Y,NIF=N,Truncated=Y,Break=N,FirstLetter=N]

nsTableRowGroupFrame::SplitRowGroup goes through this path.

Then when we reflow these frames again on the next page, we get to the block 16980 but it chooses to optimize away reflowing its child the table-wrapper 16a40.

It's not clear to me what should have made it do otherwise, given the information it had.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It occurs to me that the ReflowInput::mFlags::mMovedBlockFragments added in https://hg.mozilla.org/mozilla-central/rev/c3cbe1928fea might be helpful here.

Comment 7

[Mats Palmgren (inactive)]

The testcase works fine for me in a recent Nightly on Linux. I can reproduce it v72 though which suggests this was fixed recently. (Adding regressionwindow-wanted in case anyone wants to investigate what bug fixed it.)