1648947 - Broken print output from Yahoo Mail, because element with "display:table" doesn't print correctly - initial blank pages, missing content, and content that runs off the page

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect)

Description

[Ron]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

Trying to print a email of a purchase. It contains the header and a long but narrow block of information containing logos, invoice number, charge information and other notes. Items can be highlighted to copy info. It has borders and shading.

1. Click on your Yahoo email message to view it. Click on the Printer Icon and another screen appears with only the message and a printer dialog window. Click OK to print.

==============
I must point out I have Windows Pro 7. In my troubleshooting I wanted to setup the printer settings that all applications will receive globally. I first went into the Devices and Printers option, right click over the printer and chose Printing Properties, clicked on the Advanced Tab, clicked on Printer Defaults and the effects tab. There is a Print Task Quick Set that has a Default Print Settings option. I chose it and set Fast Draft Printing. Besides it resetting to defaults, I am particularly interested what is the default setting in the Resizing Options. It appears to set to Actual Size. Nothing in these settings I see could be causing the problem in your browser.

In Firefox, when you do a print preview and click page setup, you have the option to print the background (Color and Images) if your on Yahoo email. Everything you see on the page on screen will output to print, including background color and images. I turned this option off. The scale is set to 100%. I printed and the result is no error as I mentioned. Everything printed except since I have my screen set to 1920 by 1020 (HD Smart TV) the output is magnified and split vertically. Two pages printed but the cutoffs are not printed onto other pages.

When you click on the print icon inside your yahoo message and see the preview windows of your message, there is on the upper right corner of the message window you see three bars. You click on this and you get all the options you would when you click these three bars in you browser on the upper right corner. Now click print option and you go into a preview scree. NOW YOU SEE THE PROBLEM I DESCRIBED BEFORE IT PRINTS. WOW! THERE IT IS. It doesn't matter if I click on or off to print the Background (Colors and Images) it has no effect in correcting the output preview that will be on paper.

How are you guys going to fix this. There are users of older equipment with earlier versions of Firefox, Windows, Linux, etc. This fix should be an update patch that runs for all Firefox versions. And your browser should be smart enough to page break after a line of text in image.

Actual results:

The preview of the message has no page breaks. You can see this by scrolling the the message onscreen. The printer output produces a page with header information only and the rest is all white space. The second page shows the message body (long block of info) clipped only showing the last end of it like the price. As if it was treated like an image. The part that should have been in the first page is not printed but the other half shows up on the second page. It is not an image since the text is selectable.

Expected results:

What should have happened is it should have printed everything it could print on a letter size page. When it reaches the bottom (the limit of the printer to print to the edge), it should continue to print the rest on the next page. That is what should have happened.

But your browser or something else is not smart enough to page break after a line of text in an image and may split a line of text horizontally in the middle leaving it unreadable.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Daniel Holbert [:dholbert]]

Hi Ron! Thanks for the bug report and I'm sorry that this happened. Unfortunately, it's hard to know what's going on without being able to see and test with the actual content that's causing this problem, which in this case means the email itself.

If you're comfortable doing so, please feel free to forward the email in question to me (email address: [e-mail]) and I can try to figure out what's causing the issue. No promises at this point that I (or another developer) will be able to fix it right away, but it will hopefully at least help us identify the particular combination of web content that's causing the problem, which is a start.

We do have some folks taking a special interest in fixing printing bugs right now and for the coming months, and there's a chance this might be an instance of a bug that's already known and perhaps even one that we've already got a fix in the pipeline for.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Ron was kind enough to send me a version of the broken email, and I reduced this testcase from it.

This testcase is super simple -- it's just a <div style="display:table"> with tall content inside of it (a bunch of dummy numbered list entries).

STEPS TO REPRODUCE:

1. Print or print-preview this testcase.

EXPECTED RESULTS:
The numbers 1 to 200, spread out over several pages.

ACTUAL RESULTS (on my system, using Firefox Nightly):

• First three pages are entirely blank.
• Page 4 has content that starts on it 2/3 of the way down (starting with line labeled 131 in print preview, 132 in printed PDF).
• Page 4's last line may be vertically clipped partway through the text -- this happens for me in print preview. There, that line is "148" but I can only see the top half of it.
• Page 5 starts at a substantially larger line-number (175 in print preview, 176 in print) -- so over 25 lines got eaten up somehow between page 4 and page 5.

This works just fine if I edit the testcase to use a <table> element instead of <div style="display:table">, for what it's worth.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: screenshot of print preview output for testcase 1

Here's a screenshot showing my print-preview ACTUAL RESULTS from previous comment. Note the first line is #131 (lots of missing lines before that), and the number at the bottom of the page is clipped, and then there's a large jump in the numeric values when we get to the next page (so there's some missing content that ran off the page).

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: printed PDF of testcase 1

And for completeness, here's testcase 1, printed to PDF.

Comment 6

[Daniel Holbert [:dholbert]]

I think this may be due to a particular rule in Yahoo Mail's print presentation of their emails. This might mean that this is a reasonably easy bug to hit for Yahoo Mail users (at least, those who print their emails), which would be pretty rough for those users.

I say that because I'm seeing display:table being applied to a "wrapper element" in Yahoo Mail's print presentation of even a trivial message that I sent to myself at a Yahoo Mail address. When I click Yahoo's print icon in their email webapp, the resulting simplified print-ready HTML document has the following markup (which I've abbreviated here):

#Atom .D_FY {
 display:table
}
[...SNIP...]
<body id="Atom" [...]>
[...SNIP...]
<div data-test-id="message-view-body" class="I_52qC D_FY W_6D6F">

All the message content are inside that "message-view-body" div, which is display:table per its D_FY class which matches the CSS rule above. This makes it potentially susceptible to this issue.

Comment 7

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Attachment: testcase 2

This works just fine if I edit the testcase to use a <table> element instead of <div style="display:table">, for what it's worth.

For a properly structured table markup, our UA gives <td> vertical-align: middle, but for <div style="display:table">, the implicitly generated nsTableCellFrame has vertical-align: baseline.

It seems we have a bug in the table cell baseline calculation if the table cell frame is fragmented, as it calculates a very large kidBStart [2] and uses it as the y position of inner -moz-cell-content block.

This testcase demostrates this bug by using <td style="vertical-align: baseline">.

[1] https://searchfox.org/mozilla-central/rev/c6676771df58c6e0098574bc6b11517acbf264cf/layout/style/res/html.css#440,453,473
[2] https://searchfox.org/mozilla-central/rev/c6676771df58c6e0098574bc6b11517acbf264cf/layout/tables/nsTableCellFrame.cpp#573,598

Comment 8

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

CC folks who might have more knowledge in baseline calculation.

Comment 9

[smayer97]

I believe this might be a duplicate of what was reported here: https://bugzilla.mozilla.org/show_bug.cgi?id=1606540

Comment 10

[smayer97]

(7 months ago)

Comment 11

[Daniel Holbert [:dholbert]]

Thanks! The testcases are somewhat different, but they do both involve tables & missing content, so it's possible.

--> Marking as "see also" for now; we can dupe later on if they are in fact determined to be duplicates.

Comment 12

[Daniel Holbert [:dholbert]]

Got a new report of this in bug 1759775 comment 19.

Comment 14

[David Smith]

Attachment: FirefoxYahooMailBug-Lowes(Firefox).pdf

Here is a failed print rendering (to PDF) of an email I received from Lowes.
The original email has been forwarded to [e-mail] and [e-mail] (because I don't know how to upload it otherwise).

Comment 15

[David Smith]

Attachment: FirefoxYahooMailBug-Lowes(MSEdge).pdf

Here is the same email printed to PDF from Yahoo Mail using Microsoft Edge.
PS: If this is not the right bug number, I apologize in advance. I'm just trying to be helpful.

Of course I confess a certain amount of self interest because printing emails is something I like to do.
At least in this case there is a workaround -- launch another browser. :-(

Comment 20

[smayer97]

Some time ago I was directed to this page: https://wiki.mozilla.org/Platform/Layout/Printing_and_fragmentation regarding tracking realted bugs. But I see that it is no longer populated. Where did all the related bugs move to?

Comment 21

[David Shin[:dshin]]

Attachment: Minim

Comment 22

[David Shin[:dshin]]

Whoops - accidentally pressed enter there.
I've rephrased the problem as the question of baseline alignment above - looks like some kind of interaction between table + lists.
Replacing the content with e.g. "hi<br>hi<br>hi<br>hi<br>[...]," the baselines align correctly and printing works as expected.

Comment 23

[David Shin[:dshin]]

Though - it looks like that may be a function of GetFirstLineBaseline) not handling empty lists well? Flex container + baseline alignment + empty lists, which utilizes this code path, seem to be broken as well. If I add any content within li baseline alignment and printing seems to behave as expected.
Since comment 3 mentions numbered list as dummy entries, my testcase is pointing at a different bug.

Comment 24

[Daniel Holbert [:dholbert]]

RE comment 21 - that might be a distinct issue, since it's an inline-table and we inherently cannot fragment display:inline-[whatever] content. (We print it using the "Fragmentation fallback", via layout.display-list.improve-fragmentation.)

Comment 25

[Daniel Holbert [:dholbert]]

hi TYLin - I think this is on our list of priority fragmentation bugs that you were aiming to look at, as discussed on slack a little while back. I'm assigning to you to be sure we've got assignees for as many S2 bugs as possible, but feel free to kick back over to me if you don't have cycles to look here. Thanks!

Comment 26

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Attachment: Bug 1648947 - Force table-cells to use 'vertical-align:top' in printing. r?dholbert,#layout

When printing tables, if a table row group is split across the page boundary,
its table-cell descendants with vertical-align:baseline|middle|bottom| do not
align as expected and there might be data loss. Currently, we reflow the table
row frames first, and then call DidResize() [1] to move table cells to their
vertical-align positions via BlockDirAlignChild() [2] . This is fine if the
table is in gallery mode or can fit in one page, but it doesn't work if it is
across the page boundary.

To fix this properly, we need to rewrite the table fragmentation code so that
the a table cell is reflowed in its aligned position with a correct constrained
available bsize. In the meantime, this patch workarounds the data loss by
forcing table-cells to use vertical-align:top. This is a hack, but it also
matches Google Chrome's current behavior. I feel this is a good interim solution
to improve our printing quality.

[1] https://searchfox.org/mozilla-central/rev/2537e5eaafaab9a7ef6be5cfc8e9b1e2c747fdfd/layout/tables/nsTableRowGroupFrame.cpp#1119-1125
[2] https://searchfox.org/mozilla-central/rev/2537e5eaafaab9a7ef6be5cfc8e9b1e2c747fdfd/layout/tables/nsTableRowFrame.cpp#370-372

Comment 27

[Daniel Holbert [:dholbert]]

I took a quick look at some testcases here, including some emails in Yahoo Mail that supposedly used to reproduce this. In Yahoo Mail, it seems maybe this has been worked around on their end, at least in the testcase that I'm looking at? The email whose print-presentation I'm looking at has vertical-align:top in the inline style of all of its td elements, like so:
<td style="border-collapse:collapse;color:rgb(10,10,10);font-family:Helvetica, Arial, sans-serif;font-size:14px;font-weight:normal;line-height:1.2;margin:0px;padding:0px;text-align:left;vertical-align:top;">

So when we're looking to validate the fix here, it's possible that Yahoo Mail itself doesn't reproduce the issue anymore and hence won't produce a clean "bad before, good after" comparison. But the html testcases attached on the various associated bugs should still function as ways to validate the fix. (And from my quick testing in code review, this does seem to fix them -- hooray!)

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e1eaa4209a62
Force table-cells to use 'vertical-align:top' in printing. r=dholbert

Comment 29

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/e1eaa4209a62