895934 - 17.0.7 Won't print a certain mail (involving fonts), but printing reply to that mail works [multipart/alternative]

Status: NEW

(MailNews Core :: MIME, defect)

Description

[accounts]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.72 Safari/537.36

Steps to reproduce:

I am trying to print an email. Whether using the right click feature or the menu feature on either the default printer or other printer. It doesn't matter, it just doesn't print.


Actual results:

Nothing. 


Expected results:

It should have printed.

Comment 1

[Wayne Mery (:wsmwk)]

Does it fail in safe mode? 
http://support.mozillamessaging.com/en-US/kb/safe-mode

If it fails in safe mode, the path of least resistance I think is to try the beta version from http://www.mozilla.org/thunderbird/channel/ which has about one year of accumulated fixes.

Comment 2

[accounts]

Yes. I found a work around. Apparently the error is with one of the fonts contained in the emails I was trying to print. I simply replied to the email, highlighted all the text and converted it to arial then tried printing the email and it works fine. So there is still some kind of font bug somewhere in thunderbird.

Comment 3

[Wayne Mery (:wsmwk)]

See if an error is noted in tools | error console

Comment 4

[Thomas D. (:thomas8)]

I don't think there's a font bug in TB, and I don't see that proven yet.

accounts (reporter), we need an affected msg as a testcase for reproducing yr problem. can you press Ctrl+U on affected msg in msg reader, then save source as txt file, remove private data (mail addresses etc.) with text editor, then attach msg source to this bug using "add an attachment" link above?

Comment 5

[accounts]

Attachment: Testcase1.eml: source of msg that won't print

Here is the email that you requested. I opened it up to view it, CTRL + U and saved as email.txt

I then opened the text doc and removed all private information out of the email. Let me know if you need anything else?

Comment 6

[accounts]

I cleared my error log, and did what wayne suggested. I opened the email and tried printing it again. Here is the resulting error: 

Timestamp: 7/29/2013 11:29:01 AM
Warning: XUL box for _moz_generated_content_before element contained an inline #text child, forcing all its children to be wrapped in a block.
Source File: chrome://messenger/content/messenger.xul
Line: 0

Like I said. If I click reply to the email and highlight the text of the email and change it to "Arial" font for instance, it prints fine.

Comment 7

[Thomas D. (:thomas8)]

accounts, thanks for fast response & testcase, that's very helpful :)

Hmm, odd indeed, and not printing what's on screen. 

STR

1 open testcase1 attachment 782621 [details] in preview, it's own tab, or window
2 print preview
3 print (from print preview, or directly from msg reader)

4 remove font face attribute from source, e.g. here
><p><font color=3D"#0000ff" size=3D"3" face=3D"Roman"><em>who<=
-> <p><font color=3D"#0000ff" size=3D"3"><em>who<=
5 print preview
6 print


Actual result

1 although message is multipart/alternative, both parts are shown (not sure if that's expected??). Note that the textual content of both parts differs, also odd, but still...

Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

2 print preview shows only this part:

Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

So the text/html part which is seen below text/plain part in msg reader is ommitted in print preview (this bug).

3 print shows nothing at all (not even what we saw in print preview)

4 after removing a font face attribute, that (blue) line will actually show in print preview...

5 ...but still nothing at all (blank page) when printing.

This needs WADA's wisdom :)

Don't see any exact dupes in tentative search -> confirming

:thun,mail not,wont,"n't",refus,blank,empty print
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%3Athun%2Cmail%20not%2C%22n%27t%22%2Cwont%2Crefus%2Cblank%2Cempty%20print&list_id=7398164

Comment 8

[accounts]

Yeah....weird. If you change all the font face to a system font like arial, it should print exactly what you see on screen.

Comment 9

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #7)
comment 7 was tested only against TB 17.0.7 on WinXP, still need to check on trunk

Comment 10

[accounts]

Ah if it helps any...

TB version 17.0.7

OS Name	Microsoft Windows 7 Professional
Version	6.1.7601 Service Pack 1 Build 7601
Other OS Description 	Not Available
OS Manufacturer	Microsoft Corporation
System Name	JON-HP
System Manufacturer	Hewlett-Packard
System Model	HP Compaq 6005 Pro MT PC
System Type	x64-based PC
Processor	AMD Phenom(tm) II X3 B75 Processor, 3000 Mhz, 3 Core(s), 3 Logical Processor(s)
BIOS Version/Date	Hewlett-Packard 786G6 v01.15, 8/2/2011
SMBIOS Version	2.6
Windows Directory	C:\Windows
System Directory	C:\Windows\system32
Boot Device	\Device\HarddiskVolume1
Locale	United States
Hardware Abstraction Layer	Version = "6.1.7601.17514"
User Name	Work-HP\VP
Time Zone	Central Daylight Time
Installed Physical Memory (RAM)	4.00 GB
Total Physical Memory	3.50 GB
Available Physical Memory	1.29 GB
Total Virtual Memory	7.00 GB
Available Virtual Memory	3.66 GB
Page File Space	3.50 GB
Page File	C:\pagefile.sys

Comment 11

[WADA:World Anti-bad-Duping Agency]

(Q1) How did you view the mail when you tried to print?
(a) Open the .eml file by Tb
(b) Mail held in Tb's mail folder.

Quick check result with Tb 17.0.7 on Win-XP.
(1) Drag&Drop the .eml file to Thread Pane of local mail folder.
    (import of .eml file by Drag&Drop)
(2) View/Message Body As/Original HTML, Print Preview
    => data in text/plain part is shown
(3) View/ Message Body As/Original HTML, Print Preview
    => data in text/html part is shown

(Q2) With which View/Message Body option?
     Do you see your problem with (d) Simple HTML or (e) Plain Text?
     What is difference among followings?
     (c) View/Message Body As/Original HTML
     (d) View/Message Body As/Simple HTML
     (e) View/Message Body As/Plain Text

If .eml file, Tb still has many problems. See dependency tree for meta Bug 269826.
Please check with "mail in Tb's folder" first, and check with ".eml file" additionally, plase.

Test mail is quoted-printable. If quoted-printable, problem like bug 571704, bug 598740, which has been fixed by bug 594646(FIXED in Tb 24) may be relivant to your problem.

(Q3) Can you see your problem with 
     (f) Content-Transfer-Encoding : 7bits(or 8bits)?
(Q4) Do you see your problem on non multipart/alternative mail?
     (g) mail of text/plain in quoted-printable
     (h) mail of text/html  in quoted-printable

If your problem is observed with (h), check with simplest text/html & quoted-printable mail, with minimum HTML source, please.

Comment 12

[WADA:World Anti-bad-Duping Agency]

Attachment: Minimum test mail : text/html mail(non multipart), 7bits

Sorry, I misunderstood displayed result.
In both Original HTML and Simple HTML, text/html part was used correctly.

Phenomenon was;
(i) Following <p> in <div> after <p>Thank you!</p> is;
> <div style="FONT-FAMILY: Tahoma; FONT-SIZE: 13px">
> <p><font color="#0000ff" size="3" face="Roman"><em>###-###-#### fax</em></font></p>
> </div>
- Message Body As/Original HTML : Not shown by Print Preview.
- Message Body As/simple   HTML : shown by Print Preview as expected.

(ii) (i) is observed on "text/html mail" in "7bits".
     i.e. multipart/alernative, quoted-printable, are not relevant.

Sorry for my confusion.

Comment 13

[WADA:World Anti-bad-Duping Agency]

Attachment: Minimum test mail : text/html mail(non multipart), 7bits, no <meta>

Sorry, previous one contained partially incorrect <meta> in HTML.
Bad and irrelevant <meta> is removed to avoid confusion and misleading.

Comment 14

[WADA:World Anti-bad-Duping Agency]

FYI.
http://www.w3schools.com/tags/att_font_face.asp
> The <font> tag is not supported in HTML5.
> The face attribute of <font> is deprecated in HTML 4.01.
And, following is stated for <FONT FACE> of older HTML version.
> You should end the list with a generic font (serif, sans-serif, monospace, cursive or fantasy),
> to let the browser pick a font that is in the generic family, if no other fonts are available.

Font face name is case insensitive? Or case sensitive?

Comment 15

[WADA:World Anti-bad-Duping Agency]

FYI.
As Thomas D. says, text is shown in PrintPreview by "face in <font> tag => faceX"(identical to "remove face attribute") even when View/Message Body As/Original HTML.

Comment 16

[WADA:World Anti-bad-Duping Agency]

"shown by PrintPreview, but nothing is printed by Print" part may be:
  No fallback generic font name in CSS(style="font-family: Tahoma; ..."),
  then nothing is printed because no font is usable in printing.
Can style="font-family: Tahoma,serif; ..."(with replacing face by faceX) be workaround?