Open Bug 1648947 Opened 1 year ago Updated 11 months ago

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


(Core :: Printing: Output, defect)




Webcompat Priority ?


(Reporter: bugreport101-1000, Unassigned)


(Blocks 1 open bug)


(Whiteboard: [frag2020])

User Story

See comment 3 for testcase and steps to reproduce.


(4 files)

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.

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

Component: Untriaged → Printing: Output
Product: Firefox → Core

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

Severity: -- → S3
Flags: needinfo?(bugreport101-1000)
Attached file 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).


  1. Print or print-preview this testcase.

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.

Ever confirmed: true
Flags: needinfo?(bugreport101-1000)
Summary: Printing Error: Body of message prints on second page, first page only header → Elements with "display:table" don't print correctly - initial blank pages, missing content, and content that runs off the page
User Story: (updated)

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

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

Attachment #9165542 - Attachment description: printed PDF → printed PDF of testcase 1

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 {
<body id="Atom" [...]>
<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.

Blocks: 521204
Summary: Elements with "display:table" don't print correctly - initial blank pages, missing content, and content that runs off the page → 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
Whiteboard: [frag2020]
Version: 77 Branch → Trunk
Attached file 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">.


CC folks who might have more knowledge in baseline calculation.

I believe this might be a duplicate of what was reported here:

(7 months ago)

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.

See Also: → 1606540
Webcompat Priority: --- → ?
You need to log in before you can comment on or make changes to this bug.