emoticons print as squares with strange contents



12 years ago
10 years ago


(Reporter: servizio.antifumo, Unassigned)


Windows XP

Firefox Tracking Flags

(Not tracked)



(2 attachments)



12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070725 Firefox/
Build Identifier: (20070728)

When printing a message containing emoticons (having the "Print background" checkbox active so that they get print), instead of getting the emoticons at their place like those shown in the print preview, a rectangle containing many very small emoticons (corresponding to the right emoticon having to be printed at that place) in different colors at the top is printed, with the rest of the rectangle being filled by random pixels.

Reproducible: Always

Steps to Reproduce:
1. Ensure that the "Print background" checkbox is checked.
2. Print a message containing some emoticons
(see additional information)

Actual Results:  
Instead of the emoticons, these rectangles with very small emoticons and random pixels are printed.

Expected Results:  
Like in print preview, having the correct images instead of these.

The emoticons are printed correctly (although with a not so nice black background) if the emoticon drop-down menu of a compose window has been displayed at least once before printing the message.

Comment 1

12 years ago
Created attachment 279388 [details]
An example of the bug


12 years ago
Attachment #279388 - Attachment mime type: application/force-download → application/pdf


12 years ago
Version: unspecified → 2.0

Comment 2

11 years ago
I could reproduce the behavior you describe (including that printing works correctly after opening the emoticon drop-down menu during composition once) on the current Thunderbird (Windows/20080213) version, but not with today's nightly trunk. The emoticon was printed correctly without the workaround with the composition window first.

This bug may have been fixed for trunk by now, I couldn't find any duplicating bug though. Not confirming since it works for me on current trunk. 

Comment 3

11 years ago
I reproduced the problem with the latest version of Thunderbird (, Windows/20080421).

I also tested this on Linux (, 20080505), and the behavior is slightly different: the emoticons are completely missing in the generated PostScript code, and after opening the emoticon drop-down menu in the composition window they appear (cropped and slightly bigger than required, but they're there).

Comment 4

11 years ago
On the same machines where you see this for the current releases, can you reproduce it with the TB 3.0 Alpha 1 (Shredder) or trunk nightly versions?


Comment 5

10 years ago
I just tried with Shredder/3.0a3 (sorry for the long delay in answering), the bug seems to be still around. Attachment with example will follow.

Comment 6

10 years ago
Created attachment 349071 [details]
Screenshot of same bug in Shredder/3.0a3

Here is an example of the bug in Shredder/3.0a3 (screenshot from print to PS file).

Comment 7

10 years ago
Thanks for reporting back. I'm still unable to reproduce this on WinXP SP2 using nightly trunk builds though. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/200811{17,20} Shredder/3.0b1pre prints emoticons correctly even without opening the smiley menu in the composition window first. Tried in both plain-text and HTML modes.

Your reference to the PostScript code in comment #6 and actually already in comment #3 made me thinking. Thus, I printed into a file using the Generic PostScript driver on Windows, but with the same result, all prints fine.

I'll leave this unconfirmed for somebody else to reproduce. This may be happening with specific conditions only. This may be some underlying memory allocation issue, if it's still present Apparently it is), but that's hard
to guess.

Comment 8

10 years ago
I'm wondering if the bug is still the same as in Thunderbird/2.0.0.x, as there is no black square with strange contents printed, but an uncentered emoticon instead, and opening the emoticons menu in the HTML compose window doesn't change anything to the result. I still have to try with the nightly trunk builds.

Comment 9

10 years ago
Ok, I confirm: the bug is NOT there in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081120 Shredder/3.0b1pre. The emoticons seem to be printed correctly (did 2-3 tests with different mails and emoticons).
per comment #9

I also can confirm as WFM here on 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090618 Lightning/1.0pre Shredder/3.0b3pre ID:20090618031425
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.