Closed Bug 1406050 Opened 7 years ago Closed 5 years ago

non-floating table doesn't show up after page-break-after

Categories

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

Product:
Core
Component:
Printing: Output
Version:
56 Branch
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla70
Tracking Flags:
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- wontfix
firefox-esr68 --- wontfix
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 --- wontfix
firefox59 --- wontfix
firefox60 --- wontfix
firefox68 --- wontfix
firefox69 --- wontfix
firefox70 --- verified

People

(Reporter: ajajabox, Assigned: dbaron)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: dataloss, regression, Whiteboard: [layout:print-triage:p1])

Attachments

(2 files)

HtmlPage1.html
341 bytes, text/html
Details
printing frame tree
9.29 KB, text/plain
Details
Attached file HtmlPage1.html — 
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36

Steps to reproduce:

Open the HTML file in desktop FF56 and choose "Print Preview".

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8" />
  <title>test</title>
</head>
<body>
  <div style="page-break-after: always;">test1</div>
  <div>
    <div>
      <table>
        <tr>
          <td>
            <h1>test2</h1>
          </td>
        </tr>
      </table>
    </div>
  </div>
</body>
</html>




Actual results:

Firefox doesn't print text "test2" on the second page. 



Expected results:

The problem appears after "page-break-after: always;" in tables in divs in the desktop Firefox v56 (both Windows and Linux). 
Browser should print text on the second page, as it has been doing in version 55 or older.
Component: Untriaged → Printing: Output
Product: Firefox → Core
[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?
Blocks: 1308876
Status: UNCONFIRMED → NEW
status-firefox56: --- → wontfix
status-firefox57: --- → affected
status-firefox58: --- → affected
status-firefox-esr52: --- → unaffected
tracking-firefox57: --- → ?
Ever confirmed: true
Flags: needinfo?(dbaron)
Keywords: regression
Until I know more about the severity, I'd like to tag this as a 57 blocker. Hi Bob, I believe you'd worked in this area too before and any prompt help will be appreciated.
tracking-firefox57: ? → blocking
Flags: needinfo?(bobowencode)
(In reply to Ritu Kothari (:ritu) from comment #2)
> Until I know more about the severity, I'd like to tag this as a 57 blocker.
> Hi Bob, I believe you'd worked in this area too before and any prompt help
> will be appreciated.

I'm not too familiar with the layout side of printing, so I'm sorry I can't really help here.
If you need a response before dbaron gets to this, I'd try dholbert.
Flags: needinfo?(bobowencode)
Thanks Bob. Hi Daniel, should this be a b7 blocker? I am unable to judge how widespread this problem is. Any help is appreciated.
Flags: needinfo?(dholbert)
Given that we've already shipped this bug in 56, and 57 is only taking low-risk stuff at this point, I don't think this can reasonably be considered a 57 blocker.

Hypothetically if it turns out the fix is easy & safe, then it'd be worth uplifting, though.  So: I'd suggest "fix-optional" for 57.

(RE how many pages are affected -- "page-break-after" is used in ~10% of visited pages according to Google & Microsoft's usage charts:
  https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/?q=page-break-after
  https://www.chromestatus.com/metrics/css/popularity#page-break-after
But I'm not sure how common the other characteristics are that trigger this bug.  And printing is not a super-common usecase.  Still: dataloss when printing [e.g. missing content] is pretty bad.  So, high-priority bug, but again, I don't think it should block 57.)
Blocks: 521204
Flags: needinfo?(dholbert)
Keywords: dataloss
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.
Summary: Printing problem → non-floating table doesn't show up after page-break-after
and after page-break-before
Any progress?
Attached file printing frame tree — 
This shows the frame tree that we print; the problem seems to be that the block inside the table cell is leaving its contents on the overflow-lines list.
I think I need to work out a set of rules for when things should get marked dirty (or has-dirty-children) during page/column breaking.  We don't really have a good one.

I suspect the rule that applies here is that if we change a state from not-complete to truncated, then we need to mark everything from the original not-complete frame up to the point that changed it to truncated as has-dirty-children so that we reflow them again and redo the breaking.  I think that's roughly the problem here, although in this case the transition from not-complete to truncated was a bit strange:

>               block 0x55d161c69f98 Reflow d=5440,1 status=[Complete=N,NIF=Y,Truncated=N,Break=N,FirstLetter=N]
>              cell 0x55d161c69c18 Reflow d=5560,121 status=[Complete=N,NIF=Y,Truncated=Y,Break=N,FirstLetter=N]
>             row 0x55d161c69748 Reflow d=5560,121 status=[Complete=N,NIF=N,Truncated=Y,Break=N,FirstLetter=N]
>            rowG 0x55d161c69290 Reflow d=5560,5012 status=[Complete=Y,NIF=N,Truncated=Y,Break=N,FirstLetter=N]
>           tbl 0x55d161c68c40 Reflow d=5800,5252 status=[Complete=Y,NIF=N,Truncated=Y,Break=N,FirstLetter=N]
>          tblW 0x55d161c68ba8 Reflow d=5800,5252 status=[Complete=Y,NIF=N,Truncated=Y,Break=N,FirstLetter=N]
>         block 0x55d163561468 Reflow d=39360,5252 status=[Complete=Y,NIF=N,Truncated=Y,Break=N,FirstLetter=N]
>        block 0x55d163561250 Reflow d=39360,5252 status=[Complete=Y,NIF=N,Truncated=Y,Break=N,FirstLetter=N]
>       block 0x55d163560620 Reflow d=39360,52456 status=[Complete=N,NIF=Y,Truncated=N,Break=N,FirstLetter=N]
>      block 0x55d16355d400 Reflow d=40320,52936 status=[Complete=N,NIF=Y,Truncated=N,Break=N,FirstLetter=N]
>     canvas 0x55d16355d180 Reflow d=40320,52936 status=[Complete=N,NIF=Y,Truncated=N,Break=N,FirstLetter=N]
>    PageContent(-1) 0x55d16355d040 Reflow d=40320,52936 status=[Complete=N,NIF=Y,Truncated=N,Break=N,FirstLetter=N]

(note the cell and row were both not-complete *and* truncated)
Is there any chance that the bug will have been fixed before the next ESR?
Flags: needinfo?(dbaron)
Unfortunatly, you've transfered this bug into ESR.
No it's not possible to use FF in my company at all, because it breaks our multipages printing forms :(
It looks like the needinfo might have been removed by accident here, so adding it back just in case.
Flags: needinfo?(dbaron)
Worth testing if either bug 1459937 or bug 1474771 fixes this; if not, we should look again after bug 1474771 is done.
Regressed by: 1308876
No longer regressed by: 1308876
No longer blocks: 1308876
Regressed by: 1308876

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

Whiteboard: [layout:print-triage:p1]
Assignee: nobody → dbaron
Status: NEW → ASSIGNED
Depends on: 1404868
Flags: needinfo?(dbaron)

Fixed by bug 1404868.

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
status-firefox70: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla70

FF Nightly 70.0a1 (2019-08-05) (64-bit)
The problem still appears with nested tables:

<!DOCTYPE html>

<html>
<head>
	<meta charset="utf-8" />
	<title>test</title>
</head>
<body>
	<div style="page-break-after: always;">test1</div>
	<table>
		<tr>
			<td>
				<table>
					<tr>
						<td>
							<h1>test2</h1>
						</td>
					</tr>
				</table>
			</td>
		</tr>
	</table>
</body>
</html>
'''
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Please file additional testcases in new bugs; using the same bug to track multiple fixes isn't practical.

Status: REOPENED → RESOLVED
Closed: 5 years ago → 5 years ago
status-firefox70: affected → fixed
Resolution: --- → FIXED

(And yes, I'm aware there are other pretty related issues, such as those in bug 1406163; I still need to figure out what the underlying general principles are about how this code ought to work, and sometimes that requires additional examples that show that the principles I figured out before aren't correct. But from a bug tracking perspective, bug reports become very confusing and basically unusable if there isn't a simple way to answer yes or no to the question of whether the bug is fixed.)

Flags: needinfo?(dbaron)
Flags: needinfo?(dbaron)
Flags: qe-verify+

Hello!
Reproduced the issue with Firefox 58.0a1 (20171005220204) on Windows 10x64. The issue is verified with Firefox 70.0b9 (20190923154733) on Windows 10x64.

Status: RESOLVED → VERIFIED
status-firefox70: fixed → verified
Flags: qe-verify+
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: