Bug 177823

Fresh install from rawhide 2006-01-23, still no proper icon in gnome window list
applet, or thunderbird window itself, ok on gnome menu

Similar whith today release (Thunderbird 1.5 20060128) thunderbird-1.5-2

Raising the priority as the lack of a quickly identifiable icon in the task list
does make it difficult to identify the "anonymous" thunderbird window while
multi-tasking.

Me too here post:

   I get the generic X app icon on KDE (FC5T2)

I am seeing the box without the ICON for both the alt-tab switching and with the
windows list.

Thought I'd better investigate a few of the "obvious" potential reasons ...

$ sh -x thunderbird
+ MOZ_LIB_DIR=/usr/lib
+ '[' -x /usr/lib64/thunderbird-1.5/thunderbird-bin ']'
+ MOZ_LIB_DIR=/usr/lib64
+ MOZILLA_FIVE_HOME=/usr/lib64/thunderbird-1.5
+ MRE_HOME=/usr/lib64/thunderbird-1.5
+ export MOZILLA_FIVE_HOME MRE_HOME
+ MOZ_PROGRAM=/usr/lib64/thunderbird-1.5/thunderbird
+ MOZ_CLIENT_PROGRAM='/usr/lib64/thunderbird-1.5/thunderbird -remote'
+ MOZARGS=
++ check_running
++ /usr/lib64/thunderbird-1.5/thunderbird -remote 'ping()'
++ RETURN_VAL=2
++ '[' 2 -eq 2 ']'
++ echo 0
++ return 0
+ ALREADY_RUNNING=0
+ '[' -z '' ']'
+ '[' 0 -eq 1 ']'
+ rm_shit
+ find /home/andy/.thunderbird -name XUL.mfasl
+ xargs rm -f
+ exec /usr/lib64/thunderbird-1.5/thunderbird

$ cat /usr/share/applications/mozilla-thunderbird.desktop 
[Desktop Entry]
Version=1.0
Encoding=UTF-8
Name=Thunderbird Email
GenericName=Email
Comment=Send and Receive Email
Exec=thunderbird
Icon=thunderbird.png
Terminal=false
Type=Application
StartupWMClass=Thunderbird-bin
X-Desktop-File-Install-Version=0.10
Categories=Network;Application;X-Fedora;

$ locate thunderbird.png
/usr/share/icons/crystalsvg/16x16/apps/thunderbird.png
/usr/share/icons/crystalsvg/32x32/apps/thunderbird.png
/usr/share/pixmaps/thunderbird.png

]$ ls -l /usr/share/pixmaps/thunderbird.png
-rw-r--r-- 1 root root 21835 May 13  2005 /usr/share/pixmaps/thunderbird.png

$ file /usr/share/pixmaps/thunderbird.png
/usr/share/pixmaps/thunderbird.png: PNG image data, 152 x 152, 8-bit/color RGBA,
non-interlaced

$ gthumb /usr/share/pixmaps/thunderbird.png
<<looks good, proper mozilla thunderbird icon>>

$ cat /usr/share/applications/redhat-email.desktop
[Desktop Entry]
Name=Email
...
Comment=Send email and manage your schedule
...
Exec=launchmail
Icon=redhat-email.png
NoDisplay=true
Terminal=0
Type=Application
Encoding=UTF-8
Categories=X-Red-Hat-Base;X-Red-Hat-Base-Only;Network;Application;
StartupNotify=True

$ which launchmail
/usr/bin/launchmail

$ ls /usr/share/pixmaps/redhat-email.png
/usr/share/pixmaps/redhat-email.png

$ file /usr/share/pixmaps/redhat-email.png
/usr/share/pixmaps/redhat-email.png: symbolic link to
`../icons/Bluecurve/48x48/apps/redhat-email.png'

$ file /usr/share/pixmaps/../icons/Bluecurve/48x48/apps/redhat-email.png
/usr/share/pixmaps/../icons/Bluecurve/48x48/apps/redhat-email.png: symbolic link
to `icon-email.png'

$ ls -l /usr/share/icons/Bluecurve/48x48/apps/icon-email.png
-rw-r--r-- 1 root root 2642 Feb  1 20:17
/usr/share/icons/Bluecurve/48x48/apps/icon-email.png

$ file /usr/share/icons/Bluecurve/48x48/apps/icon-email.png
/usr/share/icons/Bluecurve/48x48/apps/icon-email.png: PNG image data, 48 x 48,
8-bit/color RGBA, non-interlaced

$ gthumb /usr/share/icons/Bluecurve/48x48/apps/icon-email.png
<<looks good, redhat envelope and stamp icon>>

/me scratches head ...

One strange thing I noticed about starting thunderbird, the ICON is in the
window list during initial loading of thunderbird. The ICON turns to default no
icon status shortly after the throbber release the icon.

Hmm, still a problem with FC5T3 + pup-dates @ 2006-02-27.
Other app icons are normal.
Andy's analysis suggests he may be on 64 bit. I am seeing this with i386 install.

This is actually intended by upstream -- the Thunderbird icon at small sizes
looks bad because it is so complex -- and they would rather distribute no icon
than a bad looking one.

Seems an odd decision to me, on windows at least, the 16x16(?) thunderbird icon
looks equally as good as the firefox icon, the FX icon is instantly recognisable
on Linux at that size but thunderbird with this stock icon "submarines" out of
view :-(

Judging by the number of "me too" replies on this bug is it worth trying to
persuade upstream to change their behaviour, or is there a hidden
"display_generic_icon_below_x_pixels" pref?

Created attachment 125286 [details]
composed screen showing the 3x dodgy icons

Just to ensure that we are talking about the same thing, see the 1000 words.

You'll notice that the task-selector bar @ 32x32 (i guess) also has the
problematic icon, when it needn't have it.

Two solutions: 
. use a 16x16 crafted icon rather than trying to scale a big one down; there is
nothing wrong with the one displayed in the gnome menu ? It's beautiful ;-)
. use at least a mail-like icon eg redhat/gnome (the one in the launcher
toolbar.) As also shown in the screen shot at 16x16, and looking dandy :)

Is the icon controlled by the window manager, or the app itself ? Is there a
requirement that image must be 32x32 and the wm scale it to the size it wants ?
Given the icon is not used anywhere else at 32x32, could we place a 16x16 icon
inside the file named for 32x32. Then scaling would not need to be performed
(except for the bigger one in the window list - rarely seen), leading to a
clearer image.

Going back 15 years to win3.1 days doesn't appeal to me in the least. I'd
rather not be using the OS considered the "laughing stock" ;)  [please take as
gentle jibe!]

At least on kde, it seems that you can restore the thunderbird icon in the
taskbar by copying mozilla/other-licenses/branding/thunderbird/default.xpm from
the source tree to /usr/lib/thunderbird-1.5/chrome/icons/default/  (you'll need
to make this directory first, as it does not exist by default).

Personally, I think the "thunderbird" icon thus produced is infinitely
preferable to the naff old "X" Icon seen previously.  I don't see why it's
supposed to look bad, to me it looks just as good as the firefox icon.

See also: https://bugzilla.mozilla.org/show_bug.cgi?id=284962 and
https://bugzilla.mozilla.org/show_bug.cgi?id=171349

The argument that upstream wants this seems strange since the icon appears when
you run their nightly builds.

I've modified the SPEC file to add (at the end of the install phase

# 177823
%{__mkdir_p} $RPM_BUILD_ROOT%{tbdir}/chrome/icons/default
%{__cp} other-licenses/branding/thunderbird/default.xpm \
	$RPM_BUILD_ROOT%{tbdir}/chrome/icons/default/	

And the icon is back for me. Firefox spec already contains the "nearly" same
commands :

%{__mkdir_p} $RPM_BUILD_ROOT%{ffdir}/chrome/icons/default/
%{__cp} %{SOURCE23} $RPM_BUILD_ROOT%{ffdir}/chrome/icons/default/default.xpm
%{__cp} %{SOURCE23} $RPM_BUILD_ROOT%{ffdir}/icons/default.xpm

*** Bug 186166 has been marked as a duplicate of this bug. ***

*** Bug 186408 has been marked as a duplicate of this bug. ***

I'm using FC5 Final now and it gives me the generic X icon too.

The numbner of "dupes" and "me too" continues to accumulate, I found a similar
long running entry in Mozilla's Bugzilla, and have cross-linked the two in the
hope that one of the other might get some attention ...

https://bugzilla.mozilla.org/show_bug.cgi?id=284962

Me too here post:

   I get the generic X app icon on GNOME FC5 release

I was getting a generic XFCE icon under XFCE 4.2.3.2 in FC5. I copied the file
mentioned in Comment #14 and that solved the problem. Can it can be patched via
the SPEC file for future releases?

Created attachment 127004 [details]
default.xpm

Place this file in the /usr/lib/thunderbird-1.5/chrome/icons/default directory
to get your icon back. Reload Thunderbird if it was already up. I'm attaching
this so everyone doesn't have to download the src RPM to get it.

(In reply to comment #21)
> Place this file in the /usr/lib/thunderbird-1.5/chrome/icons/default directory
> to get your icon back. Reload Thunderbird if it was already up. I'm attaching
> this so everyone doesn't have to download the src RPM to get it.

Works for me.  Thanks.  (Note that the icons/default directory needs to be created.)

So this is a Gnome, Redhat or Mozilla decision?  Judging by the some horrendous
icons included in FC5, I can't imagine it's something that Redhat did?

Look at Ekiga's icon and tell me if you can make any sense of that...

Created attachment 128059 [details]
K menu with Thunderbird icon

16 x 16 icon looks just fine

Created attachment 128060 [details]
task bar without Thunderbird icon

a 16 x 16 icon would still be better than X

Probably redundant info :
Manually copying "/usr/lib/thunderbird-1.0.7/chrome/icons" (from FC4) to
"/usr/lib/thunderbird-1.5/chrome/icons" (FC5) yields all icons (composer,
address book, etc.).

Build your own rpm with the instructions described on
http://fedoranews.org/tchung/thunderbird/.

If you use the spec file mentioned there and rebuild the rpm with the latest tar
ball the icon is there again. I did so for TB 1.5.0.2 and it works.

You need to bump the version inside the spec file from 1.5 to 1.5.0.2 if you use
the 1.5.0.2 tar ball from mozilla the ftp because the example is for 1.5.

Amazing... with the updated 1.5.0.2 RPM released yesturday this is still not
fixed. It's a simple SPEC file update guys...

(In reply to comment #28)
> Amazing... with the updated 1.5.0.2 RPM released yesturday this is still not
> fixed. It's a simple SPEC file update guys...

Additionally, the workaround in comment #21 no longer works for me.

Why are we deliberately making things uglier?

(In reply to comment #29)
> Additionally, the workaround in comment #21 no longer works for me.

OK, the workaround does work.  The icon file now needs to go in
/usr/lib/thunderbird-1.5.0.2/chrome/icons/default, which probably should have
been obvious.

(In reply to comment #30)
>OK, the workaround does work.
The workaround did not work for me with version 1.5.0.2. I worked with 1.5 just
fine.

Unbelievable : still not corrected with 1.5.0.4 package.
Furthermore, the workaround doesn't work anymore !!

oll:  The workaround works here.  I just moved the icons folder from
thunderbird-1.5.0.2/chrome to .4/chrome.

Can we get an official word from RedHat why this bug hasn't fixed since a work
around has been provided? Thunderbird is one of the very few apps that the icon
is broken on. Seems like a simple fix to me. 

Indeed.  The spec file change needed is very minor, what's wrong with putting it in?

FWIW this is my addition to the end of the install phase in the spec file:-

%{__mkdir_p} $RPM_BUILD_ROOT%{tbdir}/chrome/icons/default
install -m644 dist/thunderbird/chrome/icons/default/* \
         $RPM_BUILD_ROOT%{tbdir}/chrome/icons/default/

- basically the same as Remi's change above.

*sigh*

The Thunderbird 1.5.0.4 RPM was just released to updates today and this is still
not fixed.

Does anyone at RedHat read their bugs?

Hello? Anyone home? 6 months go buy for a 3 line SPEC FILE change.

(In reply to comment #33)
> oll:  The workaround works here.  I just moved the icons folder from
> thunderbird-1.5.0.2/chrome to .4/chrome.

Doesn't work for me in FC5.

(In reply to comment #37)

> Doesn't work for me in FC5.

The workaround works for me in FC5.  I copied:

/usr/lib/thunderbird-1.5.0.4/icons/mozicon16.xpm

to

/usr/lib/thunderbird-1.5.0.4/chrome/icons/default/default.xpm

Then restarted Thunderbird.

Always the users are pushed to post bugs to improve, fix, etc, etc. But with
this STUPID bug and one that i post for gnome-screensaver i see that time to fix
really-simple bugs is extremely big. Why this bug is not fixed yet? How we cant
believe that posting bugs will help if these post are abandoned?

Whatever... FC5 with updates to 28-jul-2006 still have the same problem.

AFAICT, it's this snippet in the specfile that's problematic (as it appears 
from cvs's 1.5.0.5-2 checkout today):

cd $RPM_BUILD_ROOT%{tbdir}/chrome
find . -name "*" -type d -maxdepth 1 -exec %{__rm} -rf {} \;
cd -

Not sure of the original rationale for omitting stuff under chrome/, but 
dropping this specfile code (and including chrome/ bits again) it makes things 
work properly.

Just to remember that this bug was not repaired in

Name        : thunderbird                  Relocations: (not relocatable)
Version     : 1.5.0.5                           Vendor: Red Hat, Inc.
Release     : 1.1.fc5                       Build Date: Tue 08 Aug 2006 09:27:18
PM WEST

Paul

Paul, tehre is no need to pile onto this bug whenever a new package is build...

Sorry Matthias, but people will keep piling onto this bug until Fedora fixes it,
since it is so annoying and ugly at the same time it is so ridiculously simple
to fix (see comment #40 (also comment #14 and comment #35)).

There is a strange statement by Christopher Aillon on comment #9. If it means
that Mozilla itself removed the icon, this is absolutely not true. The icon is
shipped on Thunderbird packages from mozilla.org, and the icon is used on
application menus from both GNOME and KDE. It was one of his own changes that
caused the icon to disappear. I tracked it down on Fedora CVS and found the
specific commit:
http://cvs.fedora.redhat.com/viewcvs/devel/thunderbird/thunderbird.spec?r1=1.43&r2=1.44


There are pretty strong arguments on comment #3, comment #10, comment #11 and
comment #13; and two still unanswered questions on comment #23 and comment #34.

If the whining here becomes too annoying, we will have to close this bug.

That arogant response was literally the straw that has broken this camel's back.
I have been a user and advocate of Redhat and Fedora systems for a number of
years. You can close this bug, you can delete my bugzilla account if you like.
Just know this, I installed kubuntu on my laptop this weekend. I believe FC5
will be the last Fedora desktop my computers will see.

I agree with Jim.  That was no way to handle a public issue.

I love Fedora but I definitely don't see any "whining" at all going on here. 
Why can't Redhat explain what the reasoning is behind the bug so everyone at
least feels they aren't ignored?  It would be just as easy as the previous
comments by Matthias.

"Good" to see that some people always ignore simple issues concerned by their 
user base. After all, the user base's opinion is nothing right? Geez, close 
this bug, ignore the user and keep this "simple bug" to annoy every user that 
uses thunderbird.

I hate being a troll, but I watched this bug for months and I didn't want to 
ignore Mathias' comment this time. When we, users, do not report bugs and 
annoyances in the bugzilla, the distro asks us to do it. When we do it, we are 
being too annoying. Blah.

Seriously Matthias, what the hell? If this is the kind of attitude you're going
to have in regard to bugs that many find a big problem, then I really need to
reevaluate my choice in distribution. Both for my own use and in what I
recommend to customers.

Up until now I've considered Red Hat's handling of bugs to be very professional.
Get your act together and don't alianate a lot of people over a trivial issue
like this.

"whining"

I can't believe it !
Sucharrogance with people simply trying FREELY to help the Fedora Project.

Amazing !

I have *never* been vocal about non-bug related comments in a Bugzilla report,
hating the whining as much as most every other, but I consider Matthias'
disappointing comment #44 unacceptable in the context of this bug's discussion ,
and a detriment to Fedora/Redhat's usual professionalism.

I fear my off-topic comment can be considered another candidate case in point to
close this bug report.

(In reply to comment #44)
> If the whining here becomes too annoying, we will have to close this bug.

Maybe we should close your bugzilla account instead, fedora doesn't need your
help to ruin its reputation, nor do my contributions to fedora warrent an
@redhat.com to speak in such way to its users and fellow contributers.

Where's the public appology?

How about we all relax and remember that this is just about a missing icon, ok ?
There is plenty of crasher bugs to fix before a missing icon becomes a priority.
If some of the energy that is wasted here could be directed towards fixing some
of those, that would be nice.

Granted there are more important bugs to fix. However, this bug :

1. has 100% end-user visibility (in contrast with some of the more obscure
crasher bugs);
2. seriously detriments end-user experience, as one cannot visually
differentiate between mail, compose, address book, ... windows ;
3. has a fix available (that is, there is no developer comment about the quality
of the aforementioned fix).

Your suggestion to limit ourselves to crasher bugs, allthough correct from a
certain point of view, suggests excluding myself - being no expert coder and not
having the inclination of becoming a Mozilla developer either - from further
contributing to a better Fedora experience by reporting bugs and/or suggesting
simple patches.

Ironically, I myself have - again by this off-topic (first time in 7 years of
RH/Fedora/Bugzilla use) comment - already invested more time than this bug
should warrant.

Matthias, if you'd just said comment #52 in comment #44, this thread would be in
much better shape.

But, if the fix is just a couple of lines in a spec file, I would hope we could
find a few minutes before FC6 to fix it.  There's low priority, and then there's
stuff that's so trivial there's no reason not to get there.

This bug feels more like the latter.

Set to block the FC6Target.

(In reply to comment #52)

> There is plenty of crasher bugs to fix before a missing icon becomes a priority.

Since 10 years I'm responsible from Linux worskstations, I rarely had so much
users complaining about one bug. All engineers here have a huge amount of
windows open in each workspace and since the mailer is their most used
application, it's really useful to switch to it easily.
Of course, it's technically near than nothing to solve it and there's far more
"serious" bugs, but an OS is like Circus : you applaud spectacular acts , far
more than the technically difficult ones.

Ok, since Max asked me nicely (hi Max !), I will apologize for the tone of 
comment #44. 

I do stand by the factual content though: too much bugzilla noise on pet bugs 
like this just lead to more important things getting lost in the noise. Every time
someone adds a "me too" or "still not fixed" comment here, this bug comes up in
our bug lists and steals a bit of concentration. If people want to have
free-ranging discussions ("threads" as Max put it), a mailing list is a much
better medium.

Matthias...

I know you've done a hell of a lot of work on Red Hat and Fedora's behalf.  I
know you're a great soldier.  But I'm sorry, I can't even support your assertion
of the correctness of the "factual content" of this as a "pet bug".

Did it ever occur to you that the "me too" syndrome in Bugzilla is actually a
*good thing*?  Even if it's a pain in your ass?  And for that matter, how many
"me too" bugs come with patches attached?

People don't bother to comment about bugs they don't care about.  They comment
about bugs that *hinder their ability to get things done*.  The metoo-ing of bug
reports may be one of our best barometers of the actual severity of a bug, in a
lot of ways.

Reading back through the history of this bug, we can see that:

1. The bug causes people serious pain, and has in fact been reported multiple
times (comments 3, 4, 5, 16, 18, 19 and notably 53);

2. The bug is trivially simple to fix -- or, if it isn't trivial, you've offered
*zero* explanation why it isn't (comments 28, 34, 35 and 36);

3. The assertion by caillon that this "bug" was in fact deliberate (comment 9)
followed by a number of eminently reasonable counter-arguments (comments 11, 12,
23, 24, and 25);

4. Numerous *actual proposed patches* have been submitted (comments 14, 35 and 40);

5. Your unwillingness even to acknowledge a patch, and your dismissal of
perfectly legitimate complaints as "whining," has *enraged* community members
(every comment after 44).

The most frustrating thing about this bug, and the reaction to it, is that has
all been so easily avoidable.  Honestly, how long would it have taken you to
incorporate (or at least comment on) the patch given to you in comment 40 by Rex
Dieter -- who, by the way, happens to be (a) the greatest champion of KDE in the
Fedora world, and (b) a member of the Fedora Board?

On the upside, I can't think of a better incentive for us to figure out how to
fix *ridiculous* problems like this one.  Sometimes public embarrassment is a
blessing.

I'm not in a position to acknowledge patches here. 

The package maintainer, who is also our closest Mozilla liaison, Chris Aillon,
has explained the reason for the current situation in comment #9 and I have no
reason to believe that he lied. So until Chris updates this bug with new
information about the situation, further comments here will not change the
situation.

Which is even more frustrating: you are speaking "authoritatively" about the bug
on the one hand, and then deferring the issue to Chris Aillon on the other hand.

Sigh.  Okay, I'll bite.

Chris, according to your comment 9: "This is actually intended by upstream --
the Thunderbird icon at small sizes looks bad because it is so complex -- and
they would rather distribute no icon than a bad looking one."

Which seems to be contradicted by comment 13 from Pierre Ossman: "The argument
that upstream wants this seems strange since the icon appears when you run their
nightly builds."

So one of the following is true:

1. The suggested patches fix the problem, we know they fix the problem, and
we're just too stubborn to put them in.  I'm pretty sure this isn't the case.  :)

2. The suggested patches do not fix the problem -- and we can't take the time to
explain why not.

3. We don't have time to verify the suggested patches and would rather leave
them alone until we do have time --and we can't take the time to explain why not.

At the *very* least, for this *particular* bug, it's time to explain the delay,
fix it if we can, defer it if we can't, and put the matter to rest.

I'll ask Chris when he's back from LinuxWorld

This is good drama!

And this is also why Bugzilla is a very good thing.  Thanks to both of you for
making this a priority.

(In reply to comment #40)
> AFAICT, it's this snippet in the specfile that's problematic (as it appears 
> from cvs's 1.5.0.5-2 checkout today):
> 
> cd $RPM_BUILD_ROOT%{tbdir}/chrome
> find . -name "*" -type d -maxdepth 1 -exec %{__rm} -rf {} \;
> cd -


This seems to be a pretty much straight copy from the firefox spec:
http://cvs.fedora.redhat.com/viewcvs/devel/firefox/firefox.spec?rev=HEAD&view=auto

However in the ff spec a few lines below it, it does:
%{__mkdir_p} $RPM_BUILD_ROOT%{ffdir}/chrome/icons/default/
%{__cp} %{SOURCE23} $RPM_BUILD_ROOT%{ffdir}/chrome/icons/default/default.xpm
%{__cp} %{SOURCE23} $RPM_BUILD_ROOT%{ffdir}/icons/default.xpm

which is missing from the thunderbird package (specificly the source23, which in
ff is the xpm icon, which is easily obtained from the tarbal)

ps while digging in this i noticed 2 more differences from the ff spec:

FF has:
%ifarch ppc ppc64 s390 s390x
%define moz_make_flags -j1
%else
%define moz_make_flags %{?_smp_mflags}
%endif
MAKE="gmake %{moz_make_flags}" make -f client.mk build

however thunderbird only has:
make -f client.mk build_all

the missing -j flags do make the build quite a bit slower on my system :-)


Also it has a flag 'official_branding' and only when it is set to '1' 'should'
the build be 'official' (just guessing here :-)), however these 2 are not
conditional in the thunderbird spec file, and arn't in the ff spec:
export BUILD_OFFICIAL=1                                                         
export MOZILLA_OFFICIAL=1

Not sure if this is intended, but it would seem that these exports contradict
the conditional 'thunderbird-mozconfig-branded' configure flag:
--enable-official-branding

This bug probably isnt the right place for these observations, but i'm in a rush
to go to work :-)

so, it's been a couple of weeks and this bug is still a pretty trivial fix, and
it's still been completely ignored.  I assume Chris is back from LinuxWorld by
now.  Can we get an update please?

I'm waiting for an answer, but just re-pinged.  Will update the bug as soon as I
know more.

On an aside, it is very strangely interesting that this bug has gotten such a
"cult following" if you will.  This isn't even the default mailer in Fedora....
Does this imply that should change?  Interesting to think about....

This probably isn't the place to discuss what should or shouldn't be the default
mail application. Where should that discussion take place? Mailing list? Forum?
Where will the "right" people see it?

I would be in favor of replacing evolution though!

*Anywhere* but here.  I'd rather get flooded by everyone personally with mails
than discuss this here.  But hopefully there are more public fora that can be found.

So, I just got an okay to do this.  The concern was that the xpm didn't look
good against certain backgrounds and a few bugs were filed about it both in RH
bugzilla and in upstream bugzilla.  As I was trying to abide by the wishes
because of the trademark guidelines at the time (we were under review), I did
remove it.  Those bugs have since been fixed and it now appears other platforms
use this and scott says he thinks its now fine, so I'm going to go ahead and
re-add the icon in the next set of builds (which will be 1.5.0.5-7)

Fantastic, thanks very much for the update Chris.

Yay! I wish you'd provided a reference for your comment #9, it didn't seem to
stand up when at least the official win32 version does ship a 16x16 icon.

Thanks.

And lo! There *was* art for alt-tab :-)

*** Bug 187291 has been marked as a duplicate of this bug. ***

I had the exact same icon problem with version 1.5.0.7 (20060913) I downloaded
today for FC5.  It was corrected by creating the directories/files by copying:

/usr/lib/thunderbird-1.5.0.7/icons/mozicon16.xpm

to

/usr/lib/thunderbird-1.5.0.7/chrome/icons/default/default.xpm

I now have icons in the tray. Thank you to davidrobertwhite (Comment 38)

Should not the package of thunderbird do that automatically during its installation?

Paul

I had the same problem in 1.5.0.10 and again it was fixed by copying:

/usr/lib/thunderbird-1.5.0.10/icons/mozicon50.xpm

to 

/usr/lib/thunderbird-1.5.0.10/chrome/icons/default/default.xpm

mozicon50 gives a much sharper alt-tab-switching image than mozicon16