Mozilla Firefox Icon is Windowing System's Standard Icon (Taskbar & Upper Lefthand Corner of App)

RESOLVED FIXED

Status

()

Firefox
General
P2
normal
RESOLVED FIXED
15 years ago
6 years ago

People

(Reporter: Biesinger, Unassigned)

Tracking

(Blocks: 1 bug, {polish, regression})

unspecified
x86
All
polish, regression
Points:
---
Dependency tree / graph
Bug Flags:
blocking-aviary1.0PR -
blocking-aviary1.0 -
blocking-aviary1.0.5 -
blocking-aviary1.5 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Not fixed on GTK1 (See Bug 242598 for what needs to be done) [asaP1])

Attachments

(8 attachments, 9 obsolete attachments)

82.49 KB, image/png
Details
825 bytes, image/png
Details
8.08 KB, image/png
Details
17.06 KB, image/png
Details
9.00 KB, image/jpeg
Details
1008 bytes, patch
Jungshik Shin
: review+
neil@parkwaycc.co.uk
: superreview+
Details | Diff | Splinter Review
6.38 KB, patch
neil@parkwaycc.co.uk
: superreview-
Details | Diff | Splinter Review
1.25 KB, patch
Details | Diff | Splinter Review
1. start phoenix
2. look in the upper left corner of the window
3. observe default windows icon

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2b) Gecko/20020927 Phoenix/0.2
(hm, just noticed, the other bugs I filed today had the same buildid of course)

Comment 1

15 years ago

*** This bug has been marked as a duplicate of 170677 ***
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
reopening.
bug 170677 is about the icon being the same as the mozilla icon (see comment 3
there)

this one is about the icon being the windows logo, so a different bug.

(I have no chrome/icons/ directory, could have something to do with this bug)
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Comment 3

15 years ago
This actually happens on Linux too - in KDE I just get the default X icon.
OS: Windows 98 → All

Updated

15 years ago
Summary: phoenix icon is standard windows icon → Phoenix icon is windowing system's standard icon

Comment 4

15 years ago
this probably depends on our getting an artist. maybe we should do something
temporary in the interim. 
Severity: normal → minor
Status: REOPENED → NEW
well, my personal opinion is that it should show at least the mozilla icon, if
no own one exists.

but sure, you might disagree, in which case this would probably be wontfix...

Comment 6

15 years ago
It seems to me that Phoenix uses a default X icon on Linux (KDE), but on w2k it
has an icon of its own (see screenshot). How about just using the same icon on
Linux as on w2k? At least that would be a good temporary solution.

Comment 7

15 years ago
Created attachment 101543 [details]
linux / windows comparison
jj: that's interesting because in my phoenix version (from sept. 27) I do not
have an icon. win98 though.

what is your phoenix version?

Comment 9

15 years ago
The one in the screenshot is either 0.2 or a very recent nightly. But as far as
I recall, it was always like that on Windows (w2k).
Nightly 20021112 on Win 98 shows the Windows icon.  Phoenix 0.4 on Win 98 shows
the Mozilla icon.
still seeing this in
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5
(if anyone cares)

Comment 12

15 years ago
*** Bug 184298 has been marked as a duplicate of this bug. ***

Comment 13

15 years ago
Appending "(taskbar)" to summary to make this bug easier to find.
Summary: Phoenix icon is windowing system's standard icon → Phoenix icon is windowing system's standard icon (taskbar)

Comment 14

15 years ago
*** Bug 185100 has been marked as a duplicate of this bug. ***

Comment 15

15 years ago
Created attachment 109250 [details]
mozdev's Phoenix icon

With regards to Asa's last comment, here is an icon used for Phoenix on
mozdev's themes page (http://themes.mozdev.org/phoenix/)... is this icon at all
official or endorsed? It's kind of fiery and distinctive (both good qualities
for a browser called Phoenix). If not, maybe it could provide a starting point.

Comment 16

15 years ago
This is _still_ happening in Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a)
Gecko/20021227 Phoenix/0.5
This is my first time on a Windows 98 PC, but it was working fine (showing
Mozilla's icon) on NT for me last week.

Comment 17

15 years ago
*** Bug 192183 has been marked as a duplicate of this bug. ***

Comment 18

15 years ago
*** Bug 193124 has been marked as a duplicate of this bug. ***

Comment 19

14 years ago
*** Bug 197554 has been marked as a duplicate of this bug. ***
I think it is Win9x bug.
In win.net server RC2, icon displayed as well.
Solved.

As mozilla, put icon file in /chrome/icons/default/.
there are two icon files required, bookmark-window.ico and main-window.ico.

before destibute Firebird(tm), put the icon and compress will solve this problem.
Thanks.
I could say good-bye to "Broken Windoze" icon now!
Thanks a lot aynilove[So,Jae-yoon], from Japan.  

Comment 23

14 years ago
Thanks for the tip. It works on linux too, but the files must be in XPM format,
and named main-window.xpm and bookmark-window.xpm. 

(The mozdev icon attached to this bug is pretty nice -- much better than default
X icon in any case.)

Updated

14 years ago
Summary: Phoenix icon is windowing system's standard icon (taskbar) → Mozilla Firebird icon is windowing system's standard icon (taskbar)
Additionary, it's not a dup of bug170677?
This bug should be moved on that bug, I guess.

Comment 25

14 years ago

*** This bug has been marked as a duplicate of 170677 ***
Status: NEW → RESOLVED
Last Resolved: 15 years ago14 years ago
Resolution: --- → DUPLICATE
I said already in comment 2 that this is not a dup of bug 170677, but oh well,
do what you want
Christian Biesinger, this bug can be fixed when
BUG170677 fixation a icon file to /chrome/icons/default/.
[see comment 21]

You may worried about BUG170677 change icon of MozillaFirebird.exe
instead of submit a icon file mentioned above.
(In this case, BUG171349 dose not fixed.)

But, it would'n be happen.
If then, we can reopen this bug. :-)

Comment 28

14 years ago
I have to agree with Christian, this is not a duplicate.  The other bug is about
replacing the current dragon head with something else.  This bug is about the
icon in the task bar being the default icon (which is generally a window with a
blue toolbar, although it can be changed) when it appears in the task bar.  You
can see this icon by creating a file with an .exe extension with no embedded icons.

I am not going to reopen it though since Mike has been complaining about me
reopening bugs.

Christian: Some questions:
current nightly?
clean profile?
any skinning applications or interface tweakers?
icon of actual executable vs. taskbar icon?

As I understand this bug, WORKSFORME
>current nightly?

I don't have the original system anymore, and if I had I wouldn't want to
download firebird anyway

>clean profile?

... how is the profile related to this bug?

>any skinning applications or interface tweakers?

no

>icon of actual executable vs. taskbar icon?

can't remember, probably the same

feel free to leave this dup/wfm, I don't really care about firebird bugs or firebird
This is no duplicate.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
I'm marking this WFM. Feel free to reopen if you see this again.
Status: REOPENED → RESOLVED
Last Resolved: 14 years ago14 years ago
Resolution: --- → WORKSFORME

Comment 32

14 years ago
I think this bug is still unresolved, but I believe it only applies to Windows
98 (and possibly earlier versions of Windows).

Using the same Firebird release 0.6 installation under Windows 2000, there is no
problem.  Under Windows 98 SE, however, the bug as originally described
persists.  I have tested using a more recently nightly build and the same
behaviour (works with Win2000, but not with Win98SE) persists.

The workaround given by aynilove@mollymail.com in comment #21 works though, and
fixes the problem under Windows 98, although it's a bit annoying to have to do this.

Therefore, the bugs technically persists, but the workaround is fairly trivial.

Comment 33

14 years ago
this bug only shows up on Win9x/ME, not 2000/XP, and it is still present in
0.6.1.  I think it should definitely be fixed, especially now that firebird has
its own icon checked in.  somebody with proper privileges please reopen this.

Comment 34

14 years ago
*** Bug 214631 has been marked as a duplicate of this bug. ***

Comment 35

14 years ago
bug 214631 says win98 only and uses recent build so I'm reopening for the minority
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 36

14 years ago
This seems to be WORKSFORME under Linux (KDE 3.1.2, using GTK2 toolkit) with UA:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030804 Mozilla
Firebird/0.6.1  I'm adding an attachment showing the icon I get.

Comment 37

14 years ago
Created attachment 129169 [details]
screenshot under linux

Icons under Linux for window/taskbar

Comment 38

14 years ago
I think it's just win98 that has it

Comment 39

14 years ago
*** Bug 215525 has been marked as a duplicate of this bug. ***

Comment 40

14 years ago
*** Bug 218095 has been marked as a duplicate of this bug. ***

Comment 41

14 years ago
I can affirm that this bug occurs with WindowsME in both 0.6.1 and the latest 
nightly build.  Neither of these zip-files contains a /chrome/icons/default/ 
directory.  Can anyone explain a workaround for Win9X systems?

Comment 42

14 years ago
Created attachment 131155 [details]
Screenshot under WinME

The attached image shows Firebird as it currently displays under WindowsME.

Updated

14 years ago
QA Contact: asa

Comment 43

14 years ago
*** Bug 220841 has been marked as a duplicate of this bug. ***

Comment 44

14 years ago
*** Bug 223659 has been marked as a duplicate of this bug. ***

Comment 45

14 years ago
*** Bug 224682 has been marked as a duplicate of this bug. ***

Comment 46

14 years ago
*** Bug 211525 has been marked as a duplicate of this bug. ***

Comment 47

14 years ago
*** Bug 221439 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Flags: blocking0.8?

Comment 48

14 years ago
This still exists on Linux, maybe not if you're using Gnome or KDE, but it does
still occur.  Running Firebird 0.7 Gentoo Linux 1.4, IceWM 1.2.13.

Comment 49

14 years ago
I see this bug on the non-XFT build of Firebird.  Noticed when using Firebird
0.7 on KDE 3.1 under Debian Linux

Comment 50

14 years ago
This should be changed from "?" to "-", since it clearly isn't a blocker. Many
bigger and more important bugs have been shifted to 0.9, so I can't imagine this
happening for 0.8.

Comment 51

14 years ago
Good god, this appears to be such an easy fix.  I found the follow:

http://extensionroom.mozdev.org/members/Jed/extensions/

and it took be about 30 seconds to fix this.  The searches to find the webpage
above took about 20 minutes.

It should be easy enough to get permission to use these icons and add.  If there
are existing icons that are just not being picked up then a similar solution
should be applicable.  

The windows icon makes FireBird look like a cheap and hacked piece of software.
 Not the stream-lined and well designed application that it is.


-Noel

Comment 52

14 years ago
The XPI linked to in comment 51 doesn't have any effect on my Linux machine. 
Icons are still the system's standard icon after installing and restarting.  The
Web page says that a Linux/Mac version is in the works, so the author apparently
knows this.  Still, since this bug is for all platforms, a Windows-only fix
would be only a partial solution.

Comment 53

14 years ago
The fix for Linux is the same as for Windows, except the icons need to be XPM
files.  Same for Mac OS X I would assume, since it is BSD based.
Moving to someone who cares. Not blocking 0.8 release.
Assignee: blake → bugs
Status: REOPENED → NEW
Flags: blocking0.8? → blocking0.8-
QA Contact: bugzilla

Comment 55

14 years ago
I had a feeling that this might be caused by the use of true colour icons, which
Win9x doesn't support (at least in the systray and window icons). Using Resource
Hacker to compare the icon group resource for Firebird with that of Mozilla, I
noted:

MOZILLA SUITE:
16 x 16 (256 colors) - Ordinal name: 1
32 x 32 (256 colors) - Ordinal name: 2

FIREBIRD:
48 x 48 (256 colors) - Ordinal name: 1
32 x 32 (256 colors) - Ordinal name: 2
16 x 16 (256 colors) - Ordinal name: 3
48 x 48 (16.8mil colors) - Ordinal name: 4
32 x 32 (16.8mil colors) - Ordinal name: 5
16 x 16 (16.8mil colors) - Ordinal name: 6

Would it be possible that Win98 is picking up the true colour icon and this is
causing it to fail? Mozilla suite only uses a 256 colour icon which appears to
work fine on Win98. The 16x16 pixel icon is also the first one in the icon group
in the Mozilla suite executable; maybe it needs to be first as well with Firebird?

Comment 56

14 years ago
I guess it's worse than that: Win98 doesn't do well on anything other than 16 
colours... (unless I'm confused with Win95)

Comment 57

14 years ago
no, no, no.  the problem is that the window icon for firebird is defined to be
that main-window.ico in chrome/icons/default.  the only problem is this file
isn't included by default.  windows xp is smart enough to use the icon included
in the exe file since it realizes that's probably better than not having an
icon, but win9x doesn't do this.  the *only* thing that needs to be done to fix
this bug is to include the icon currently built into firebird.exe as a separate
icon file at that path.  this is why i think this bug should be fixed
immediately; it doesn't require anything new at all.

Comment 58

14 years ago
Bryner's checkin on the 0.8 branch and the trunk may have some effect on this on
Linux, although I don't have time to build and check it at the moment.

(Branch)
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/browser/app&command=DIFF_FRAMESET&file=Makefile.in&rev1=1.35.2.1&rev2=1.35.2.2&root=/cvsroot

(Trunk)
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=Makefile.in&branch=&root=/cvsroot&subdir=mozilla/browser/app&command=DIFF_FRAMESET&rev1=1.41&rev2=1.42
Updating summary, adding polish keyword...

I can confirm this is still in Firefox 0.8 on Win98, if anyone wasn't sure.  I'd
also like to recommend that this be fixed sooner rather than later, as on first
glance the workaround is a bit harder to do than before.  I could probably get
it through something like ResHacker and then manually place it (haven't tried,
tho), but Joe Random User won't know this.  The icon is a bit more hidden now,
what with the trademark to protect and all.
Keywords: polish
Summary: Mozilla Firebird icon is windowing system's standard icon (taskbar) → Mozilla Firefox icon is windowing system's standard icon (taskbar)

Comment 60

14 years ago
While it's nice to learn that 2000/XP users are getting a system icon, not having one for Windows 98 
tends to make the application look unprofessional (I realize it's still being developed of course.)

The title for this bug really should be "Mozilla Firefox taskbar icon is Windows 9x's standard icon" for 
clarity.

Comment 61

14 years ago
Comment #60:  No, the summary is correct as this hits Linux also.

Tweaked summary to include icon in upper lefthand corner of app.
Summary: Mozilla Firefox icon is windowing system's standard icon (taskbar) → Mozilla Firefox Icon is Windowing System's Standard Icon (Taskbar & Upper Lefthand Corner of App)

Comment 62

14 years ago
(This comment only applies to Firefox on Linux.)

In the 0.8 builds available from mozilla.org, GTK version still has this
problem, while GTK2 + XFT one doesn't. That is, GTK2 build includes the file
chrome/icons/default/default.xpm which is used for all windows, while GTK build
doesn't even have the directory chrome/icons/. 

One very simple instruction on how to fix this with the GTK build, in case
someone hadn't figured out yet: http://iki.fi/jonik/mozilla/firefox-icons.html
(The icon is actually included in the package, but not in the right directory.)

Comment 63

13 years ago
I am adding the regression keyword because this is actually worked in the
Phoenix releases (although some of the earlier comments suggest it was broken in
the nightlies).

This bug also shows in the Mozilla suite if you delete the icons directory from
the chrome dir in Windows 98.

Expected results:
Windows 98 should show the default application icon (like win2k/xp)

Actual results:
The Windows logo (default icon) is shown

To see around the time when this regressed, I installed the following builds
(and in the case of the app suite deleted the icons directory):

Mozilla 1.2.1 and older: WORKS - deleting the icons directory defaults to the
Mozilla application icon
Mozilla 1.3a and newer: shows the windowing system default icon if you delete
the icon directory, works in Win2k and newer.

Phoenix 0.5 and older - WORKS (same as the app suite)
Mozilla Firebird 0.6 and newer + Firefox 0.8: shows window system default in
Windows 98 works in Win2k and newer.

Also seen in Mozilla Thunderbird if you delete the icons dir.

The underlying regression that's not showing the application icon by default
should be fixed, although providing an icons directory fixes the problem it
means that any new window type added (e.g. via an extension) will show the
windows default icon rather than the apps icon.

For an example of this, look at Netscape 7.1 in Windows 98 (7.0 was based on
Mozilla 1.0 which doesn't have this bug), the Netscape Network registration
pages show the Windows icon rather than the Netscape icon and the 'AIM today'
Window has the same problem. OK Netscape is all but dead, but if someone decides
to release a browser with extras like Netscape did then they might be a victim
of this bug on Windows 98.
Keywords: regression

Comment 64

13 years ago
*** Bug 236412 has been marked as a duplicate of this bug. ***

Comment 65

13 years ago
For GTK builds, the following files needed to be copied from icons/default.xpm
to chrome/icons/default after creating that directory:

bookmark-window.xpm	(Bookmark Manager)
downloadManager.xpm	(Download Manager)
main-window.xpm		(Firefox)
winInspectorMain.xpm	(DOM Inspector)
jsconsoleWindow.xpm	(JavaScript Console - Icon should work, but doesn't)

All of the above solve the icon problem except for the JavaScript Console, which
for some reason doesn't use the jsconsoleWindow.xpm like it should.

Comment 66

13 years ago
As I recall, its jsconsolewindow.xpm not jsconsoleWindow.xpm (note the lack of
capitalisation). Does this work for you?

Comment 67

13 years ago
I'm not around my Linux box at the moment, but I'll give that a try (although I
believe I may have tried that and it didn't work).

I was going off of this for the filename, which has the 'W' capitalized though:

http://lxr.mozilla.org/mozilla/source/xpinstall/packager/packages-unix#279

Comment 68

13 years ago
*** Bug 239150 has been marked as a duplicate of this bug. ***

Comment 69

13 years ago
I believe I know the problem.  I can see it comment #55 :
MOZILLA SUITE:
16 x 16 (256 colors) - Ordinal name: 1
32 x 32 (256 colors) - Ordinal name: 2

FIREBIRD:
48 x 48 (256 colors) - Ordinal name: 1
32 x 32 (256 colors) - Ordinal name: 2
16 x 16 (256 colors) - Ordinal name: 3

9x versions of windows required the ordinal numbers to be in a certian order...
we have them backwards.  I believe the 16 x 16 Icon needs to be ordinal 1 in
order for the icon to work properly.  If we just reveres the order the icons are
stored (first the 16x16, then the 32x32, and then the 48x48), this should
resolve this.

Can someone do this easily to test, or should I dig up some tools to do this?

Comment 70

13 years ago
Found it in technet:

http://support.microsoft.com/default.aspx?scid=kb;en-us;125682

Specifically this section:

Explorer displays the first defined icon in an application's resources unless
the application adds an entry to the registry...

So, we just need to make sure that the 256 Color, 16 x 16 icon is the FIRST
resource.  

I don't have access to the official graphics for Firfox, so I believe someone
else will have to fix this... unless someone can point me to (or get me) the
icon resources for this.
Flags: blocking0.9?

Comment 71

13 years ago
This is a minor polish bug. It certainly shouldn't block Firefox 0.9 which is a
feature-driven release. If it makes it in, great. If not, we shouldn't hold off
0.9 for this.
Flags: blocking0.9? → blocking0.9-

Comment 72

13 years ago
So I tried using Resource Hacker to modify the first icon, but it apparently
gets stuck in an infinite memory allocation loop and eventually runs out of
memory, without managing to replace the icon. Maybe someone who has the
facilities to build their own build can attempt to spin one with a re-ordered
resource file?

Comment 73

13 years ago
Created attachment 146999 [details]
Non-branded icon ordered as described in comment 69

This attachment has the non-branded icons ordered as described in comment 69. 
Anybody that is on Win9x, please try building and leave a comment if it solved
the problem on that platform.

Comment 74

13 years ago
A build using the non-trademarked icon with the ordering described in comment
#69 is located here:

ftp://mozilla:mozilla@rparenton.serveftp.com/mozilla/MozillaFirefox-i586-pc-msvc-Win9x_Icon_Test.7z.exe

or for those that don't want to use the link:

Host:       rparenton.serveftp.com
User:       mozilla
Pass:       mozilla
Directory:  /mozilla
Filename:   MozillaFirefox-i586-pc-msvc-Win9x_Icon_Test.7z.exe

It would really help if someone on Win9x could test this to see if it solves the
problem on that platform and then leave a comment here.

Updated

13 years ago
Attachment #146999 - Attachment mime type: application/octet-stream → image/x-icon

Comment 75

13 years ago
Taking.  I have a good idea of how to fix this on both Win9x and GTK+ linux builds.
Assignee: bugs → rparenton
Target Milestone: --- → Firefox0.9

Updated

13 years ago
Status: NEW → ASSIGNED

Comment 76

13 years ago
I tested the build provided on a Win98 SE machine, but unfortunately it exhibits
the same problem as Firefox 0.8... :-(

I'm in the process of setting up a build environment at the moment, so hopefully
I can help test any fixes...

Comment 77

13 years ago
Created attachment 147083 [details]
Non-branded icon without 32-bit icons

This icon doesn't have the 32-bit semitransparent icons in it.	It is for
testing whether Win9x will use the icon in firefox.exe with the 32-bit
semitransparent versions removed.

A build with using this file will be liked shortly.

Comment 78

13 years ago
A build using the non-trademarked icon with the 32-bit semitransparent icons
removed is here:

ftp://mozilla:mozilla@rparenton.serveftp.com/mozilla/MozillaFirefox-i586-pc-msvc-Win9x_Icon_Test_v2.7z.exe

or for those that don't want to use the link:

Host:       rparenton.serveftp.com
User:       mozilla
Pass:       mozilla
Directory:  /mozilla
Filename:   MozillaFirefox-i586-pc-msvc-Win9x_Icon_Test_v2.7z.exe

If you're on Win9x, please test this and leave a comment here.
Target Milestone: Firefox0.9 → Firefox1.0beta

Comment 79

13 years ago
I still see the default Windows icon. Using rparenton's build with an old profile.

Updated

13 years ago
Flags: blocking1.0?

Comment 80

13 years ago
Antony, can you download a ZIP build of Mozilla (Seamonkey) and rename
main-window.ico to main-window.ic_ in chrome/icons/default and see if you get
the default Windows icon then.  I'm trying to find out if Mozilla is relying on
that file for the icon on Win9x, or if the icon in mozilla.exe is the one
actually used.  If it does, this might be a bigger problem than it originally
appeared to be.

Comment 81

13 years ago
Robert, sounds like you've hit the nail on the head. I downloaded Mozilla 1.7
RC1 (installer build, not ZIP, but I don't think this should matter?) and tested
it on Win98: on a stock install, the window icon for Mozilla correctly. Renaming
chrome\icons\default\main-window.ico and restarting Mozilla made it exhibit the
same problem that Firefox. When I renamed the icon back and restarted Mozilla,
the icon reappeared.

Comment 82

13 years ago
Doing some digging, I found that Mozilla appears to set the window icon based
upon the id property of the XUL <window>. The relevant section seems to be in:

http://lxr.mozilla.org/seamonkey/source/xpfe/appshell/src/nsXULWindow.cpp#1428

where it takes "resource:///chrome/icons/default/", appends the name of the
window id to the string, and passes this to the window's SetIcon() method. In
nsWindow::SetIcon(), ".ico" is appended to this to get the full icon path.

http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsWindow.cpp#5478

So it looks like we to:

1) bundle the proper icons under /chrome/icons/default
2) remove the setting of icon based on window ID (lose the ability to have eg.
separate icons for bookmarks)
3) add a if-file-exists check before trying to load the icon, and bail out if
the file doesn't exist

I suspect what's happening is that Win9x is not being able to find the icon and
probably returning a null resource from the LoadImage() call, and so Windows is
then assigning the default Windows icon to the application. On Windows 2000/XP,
the behaviour may be a little smarter and uses the default application icon from
the executable when the icon handle is invalid.

Does that make sense to anyone? :-)

Comment 83

13 years ago
Further to this, if I create the /icons/default subdirectories underneath the
/chrome folder in my Firefox installation and copy Mozilla's main-window.ico
over here, I then get the Mozilla icon showing when I start Firefox, rather than
the default Windows icon.

Comment 84

13 years ago
Comment on attachment 146999 [details]
Non-branded icon ordered as described in comment 69

I had a feeling Mozilla (Seamonkey) would exhibit the same behavior if the icon
was renamed/removed.  This should be fairly easy to fix by just bundling the
correct icon set in chrome/icons/default/
Attachment #146999 - Attachment is obsolete: true

Updated

13 years ago
Attachment #147083 - Attachment is obsolete: true

Comment 85

13 years ago
Firefox.ico/default.xpm need to be copied to chrome/icons/default/ with the
following filenames during building/packaging:

bmPropsWindow.*		(Bookmark Properties Window)
bookmark-window.*	(Bookmark Manager)
downloadManager.*	(Download Manager)
main-window.*		(Firefox)
winInspectorMain.xpm	(DOM Inspector - Only missing on Linux GTK+ builds)

JSConsoleWindow.*	(JavaScript Console - this should be the correct case -
http://lxr.mozilla.org/mozilla/source/toolkit/components/console/content/console.xul#31)

I should have a patch to take care of this sometime soon.


As an aside, Venkman & ChatZilla may need to provide icons to be installed to
chrome/icons/default/ when they are installed as extensions.  I am not sure
about this, and it will probably need to be tested after this bug is resolved.

Comment 86

13 years ago
Not quite.  On Linux, Mozilla treats default.xpm as the fallback icon if any of
the specific icons are missing.  In this way it acts as the first resource icon
in a Windows executable.  So all the GTK1 Linux builds need is default.xpm
created in the right place.  The Windows build probably needs all those icons
created anyway.

Still, this is a bit of a quick patchup job on Windows.  Ideally, Mozilla should
be able to fall back to the first resource icon even on 9x, but that would
require a bit more work.

Comment 87

13 years ago
(In reply to comment #86)
> So all the GTK1 Linux builds need is default.xpm created in the right place.

I'm guessing you have verified that this works by testing that placing
default.xpm in chrome/icons/default/ fixes the problem in all windows.  Is that
correct?

> Still, this is a bit of a quick patchup job on Windows.  Ideally, Mozilla should
> be able to fall back to the first resource icon even on 9x, but that would
> require a bit more work.

Yes it is a quick patchup, but as you say, what you suggest probably isn't a
very trivial change.

Comment 88

13 years ago
Hmm... apparently the GTK1 builds don't pick up the default.xpm icon.  It's been
a while since I've used one of those, but I thought I remembered it working the
same way as the GTK2 builds.  Guess not.  I'm not sure *why* it doesn't do the
same thing as the GTK2 builds, but I guess that'd be another bug.

At any rate, for now it seems the GTK1 builds need the same patchup job as Win9x.

Comment 89

13 years ago
Created attachment 147163 [details] [diff] [review]
Patch for Unbranded Icons Only

Someone that is on Linux, please test this patch with a GTK1 build and verify
the following are being placed in chrome/icons/default/:

bmPropsWindow.xpm
bookmark-window.xpm
downloadManager.xpm
main-window.xpm
JSConsoleWindow.xpm

Also, please verify that the following are still being placed in icons/:

mozicon16.xpm
mozicon50.xpm

Updated

13 years ago
Blocks: 241905

Comment 90

13 years ago
Created attachment 147185 [details] [diff] [review]
Patch for Branded & Unbranded Cases

Please ignore comment #89 as this patch supercedes that one.

However, I do need someone to test this patch by building a GTK1 build on
Linux, both with and without the following flag present in .mozconfig, and then
leave comments here:

ac_add_options --enable-official-branding

I would prefer if the build was clobbered between builds with and without this
flag set.  Also, since that flag enables the trademarked artwork, please do not
distribute that build.
Attachment #147163 - Attachment is obsolete: true

Comment 91

13 years ago
This build was built using the latest patch.

ftp://mozilla:mozilla@rparenton.serveftp.com/mozilla/Firefox-win32-icon_test.exe

or for those that don't want to use the link:

Host:       rparenton.serveftp.com
User:       mozilla
Pass:       mozilla
Directory:  /mozilla
Filename:   Firefox-win32-icon_test.exe

If you're on Win9x, please test this and leave a comment here.

Comment 92

13 years ago
Created attachment 147206 [details] [diff] [review]
Patch for Branded & Unbranded Cases (GTK+ Only)

This separates the GTK+ changes so that they can be checked in before the
Windows changes, which will take longer.

The Windows changes also need to have the installer only place the icons if
Win9x is detected.  The Windows ZIP builds should always have the icons.

Updated

13 years ago
Attachment #147185 - Attachment is obsolete: true

Comment 93

13 years ago
Comment on attachment 147206 [details] [diff] [review]
Patch for Branded & Unbranded Cases (GTK+ Only)

Brian, can you take a look at these GTK+ changes.
Attachment #147206 - Flags: review?(bryner)

Comment 94

13 years ago
(In reply to comment #80)
> Antony, can you download a ZIP build of Mozilla (Seamonkey)...

Would love to help, but I have upgraded to XP, and no longer have any Windows 9x
computers at my disposal.

Comment 95

13 years ago
Sorry - wrong Antony!

Comment 96

13 years ago
(In reply to comment #91)
> If you're on Win9x, please test this and leave a comment here.
I tested this on my WinMe. The correct icon shows in:
- main browser window
- page info. dialog
- element property dialog
- download manager
- bookmarks manager
- JavaScript console
and DOM Inspector.
But help window and new extension/themes manager still show default (Windows) icon.


Is this right way for fix this problem? Yes, we can add icons for new managers
(and so on), but each icon's size is 22KB. This way will cause enlargement of
firefox...

And windows opened by any extensions will have same problem (I know
NeedleSearch). Should Extension authors also add their icons?

Comment 97

13 years ago
Robert, your build as mentioned in comment 91 works a treat. But as comment 96
noted, it won't work for any windows that do not supply their own icon files, as
it blindly attempts to load the icon even if no default is found.

I looked further at the relevant section of nsWindow.cpp, and noticed that there
are some checks for ensuring if the icon succeeds. So what I'm guessing happens
is the the LoadImage() call fails, and thus bigIcon / smallIcon shold both be
NULL. In this case, enabling the #ifdef DEBUG_law section should print a message
to the console. One would imagine that Windows would then use the application
icon, but for whatever reason, it doesn't... could be something to do with how
the window class is registered??

Comment 98

13 years ago
Comment on attachment 147206 [details] [diff] [review]
Patch for Branded & Unbranded Cases (GTK+ Only)

As I was afraid, this won't help extensions.

Antony or Anbo, if you rename one of the icon files in chrome/icons/default/ to
default.ico, does that help extensions and other windows that still display the
wrong icon?
Attachment #147206 - Flags: review?(bryner)

Comment 99

13 years ago
Created attachment 147255 [details] [diff] [review]
Makefile.in and packages_static changes to use default.ico for Windows and default.xpm for GTK+

This is not the complete patch.  More work needs to be done to make it use
default.ico and default.xpm for Windows and GTK+ respectively.
Attachment #147206 - Attachment is obsolete: true

Comment 100

13 years ago
I checked with Windows 98 and the build linked here has the unbranded icon.
Renaming one of the icons to default.ico won't help the Help window though.

Thanks to everyone working on this one, it's a nasty one on lesser windowses.

Comment 101

13 years ago
(In reply to comment #98)
> Antony or Anbo, if you rename one of the icon files in chrome/icons/default/ to
> default.ico, does that help extensions and other windows that still display the
> wrong icon?
Still shows wrong icon.

Missing icons I pointed out are:
- help.* for help window
- extensionsManager.* for new extension manager
These names of icon files are from their windows' ID. See also bug 199576
comment #1. Their filenames are of their own, so this way will make Firefox fat.


In my opinion, landing attachment 147206 [details] [diff] [review] for *0.9 branch only* is good (yes, we
need a little modification). This patch is good enough for many older windows'
users. And continue to seek better way...

Comment 102

13 years ago
I won't really have time to touch this for the next week and a half or some, so
if anybody wants to work on this, we need a function like the following for
Windows and GTK1:

http://lxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsWindow.cpp#2602

Also we need what Antony suggests in comment #82; an if-file-exists check before
trying to load the icon, and load the default icon if the file for the window ID
doesn't exist.  This would be accomplished by using the above described function.

Basically this would provide the GTK2 behavior where it falls back to
default.xpm (default.ico on Windows) if the icon for the window ID cannot be found.

If anybody wants to help work on this while I am dealing with exams, just post
patches/comments here.

Comment 103

13 years ago
From what I can tell,
http://lxr.mozilla.org/seamonkey/source/xpfe/appshell/src/nsXULWindow.cpp#1379
shouldn't need to be changed.  It appears that only
http://lxr.mozilla.org/seamonkey/source/widget/src/gtk/nsWindow.cpp#2348 and
http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsWindow.cpp#5463
will need to be modified to fall back to default.xpm/default.ico.

If I am wrong, please correct me.

Comment 104

13 years ago
This is where the default.xpm fallback was added to GTK2:

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsWindow.cpp&branch=&root=/cvsroot&subdir=mozilla/widget/src/gtk2&command=DIFF_FRAMESET&rev1=1.36&rev2=1.37

Comment 105

13 years ago
And this is the CVS checking that accomplished the default.xpm stuff on GTK2:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2002-08-10+11%3A06&maxdate=2002-08-10+11%3A08&cvsroot=%2Fcvsroot

Comment 106

13 years ago
From what it appears, the default icon is set for all toplevel windows by
default on GTK2.  I would guess if an icon with the window ID as the filename
was present in chrome/icons/default/, it would override the default icon.

This is probably the approach we should take for GTK1 and Windows.

This is the bug for the rest of the changes to the default icon code:
http://bugzilla.mozilla.org/show_bug.cgi?id=162507

These are the rest of the changes to the default icon code
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsWindow.cpp&branch=&root=/cvsroot&subdir=mozilla/widget/src/gtk2&command=DIFF_FRAMESET&rev1=1.54&rev2=1.55

Comment 107

13 years ago
*** Bug 239993 has been marked as a duplicate of this bug. ***

Comment 108

13 years ago
-> Default owner

This is much more complicated than just adding a few icon files to make it work
properly for windows from extensions, etc.  For that reason, it would be better
to have someone who actually understands that part of the code fix this.

We need a default.xpm for GTK+ and a default.ico for Windows that are used the
same way default.xpm is used for GTK2.  See comments #102-106 for the start I got.
Assignee: rparenton → firefox
No longer blocks: 241905
Status: ASSIGNED → NEW
QA Contact: bugzilla
Target Milestone: Firefox1.0beta → ---

Comment 109

13 years ago
Created attachment 147366 [details] [diff] [review]
Makefile.in and packages_static changes to package default.ico for Windows and default.xpm for GTK+ v2 (Depends on Bugs 242589 & 242599)

This one actually actually builds.  The previous version was missing a line.
Attachment #147255 - Attachment is obsolete: true
+ing since this has a patch
Flags: blocking1.0? → blocking1.0+

Updated

13 years ago
Blocks: 233462

Comment 111

13 years ago
Just to clarify, the patch only makes the changes to package
default.ico/default.xpm.  It does not make the necessary changes to the Windows
and GTK versions of nsWindow.cpp to actually use them as the default icons.

Updated

13 years ago
Whiteboard: See comment #106 for a summary of what needs to be done to fix properly

Updated

13 years ago
Whiteboard: See comment #106 for a summary of what needs to be done to fix properly → Dependencies address "proper" way to fix (hackaround doesn't fix windows from extensions)

Updated

13 years ago
Depends on: 242598

Updated

13 years ago
Depends on: 242599

Updated

13 years ago
No longer depends on: 242598, 242599
Whiteboard: Dependencies address "proper" way to fix (hackaround doesn't fix windows from extensions) → Attachment 147366, and Bugs 242598 & 242599 address "proper" way to fix (hackaround doesn't fix windows from extensions)

Updated

13 years ago
Depends on: 242050

Updated

13 years ago
Depends on: 226599

Updated

13 years ago
Depends on: 242598

Updated

13 years ago
Assignee: firefox → rparenton
Severity: minor → normal
Depends on: 242599
Target Milestone: --- → Firefox1.0beta

Comment 112

13 years ago
Spun off the default.xpm backend for GTK1 into Bug 242598 and the default.ico
backend for Windows into Bug 242599 as those are Browser-XP Toolkit/Widget
issues that need to be implemented to fix this the "right way."

This bug will focus on packaging default.xpm and default.ico once those bugs are
resolved.  Until then, this bug will focus on packaging all the necessary icons
based on XUL window ID for GTK and Windows as an interim workaround.
Status: NEW → ASSIGNED

Updated

13 years ago
Attachment #147366 - Attachment description: Makefile.in and packages_static changes to package default.ico for Windows and default.xpm for GTK+ v2 → Makefile.in and packages_static changes to package default.ico for Windows and default.xpm for GTK+ v2 (Depends on Bugs 242589 & 242599)

Comment 113

13 years ago
How about just including main-window.ico/xpm, bookmark-window.ico/xpm etc., in
the correct directory, in the 0.9 branch (as was actually proposed in comment
#101)? 

While the issue would not be "properly" fixed yet (bug 242598 and bug 242599),
it would still make a big difference if at least the main browser windows had
the correct icon out-of-the-box on Windows 9x and Linux/GTK+. (Quite a lot of
people still use e.g. Windows 98, and Firefox 0.9 would definitely appear better
to them if the icons were right.)

Comment 114

13 years ago
Comment #113, even if that is to occur, the correct time for that is after the
0.9 branch is created, which hasn't happened yet.  The correct fix for this bug
may not happen for a long time, unless someone steps up to fix Bug 242598 and
Bug 242599.

Comment 115

13 years ago
*** Bug 245069 has been marked as a duplicate of this bug. ***
Priority: -- → P2

Updated

13 years ago
Attachment #147366 - Attachment is obsolete: true

Comment 116

13 years ago
Ben, since you set blocking1.0+; FYI, fixing Bug 226599 and Bug 242050 will
solve this except for windows created by extensions.  Fixing that would appear
to require Bug 242598 and Bug 242599 to be fixed.

Comment 117

13 years ago
Did anyone get anywhere with the resource fixing to make the 16x16x256 icon the
first one in the file or was that a red herring?

Comment 118

13 years ago
(In reply to comment #117)
> Did anyone get anywhere with the resource fixing to make the 16x16x256 icon the
> first one in the file or was that a red herring?

See comments #73-81.  Especially see comment #80 and comment #81, which shows
that the icon ordering does not make a difference.

Comment 119

13 years ago
I'm sure this isn't the correct place to go, but could someone tell me how to 
remove myself from the CC list?  My email doesn't seem to show up there, but I'm 
still getting messages.

Comment 120

13 years ago
(In reply to comment #119)
> I'm sure this isn't the correct place to go, but could someone tell me how to 
> remove myself from the CC list?  My email doesn't seem to show up there, but I'm 
> still getting messages.
> 

Maybe your email is forwarded and another address is subscribed.

Comment 121

13 years ago
(In reply to comment #120)
> (In reply to comment #119)
> > I'm sure this isn't the correct place to go, but could someone tell me how to 
> > remove myself from the CC list?  My email doesn't seem to show up there, but
I'm 
> > still getting messages.
> > 
> 
> Maybe your email is forwarded and another address is subscribed.

I have already addressed this via email.  Do post any more comments about this here.

Comment 122

13 years ago
I get this problem on my Win98 machine, but my WinXP box is fine. I even ran
from the same installer exe!

Comment 123

13 years ago
*** Bug 249427 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Whiteboard: Attachment 147366, and Bugs 242598 & 242599 address "proper" way to fix (hackaround doesn't fix windows from extensions) → [ETA: As soon as icons arrive from Bugs 226599 and 242050] Attachment 147366, and Bugs 242598 & 242599 address "proper" way to fix (hackaround doesn't fix windows from extensions)

Comment 124

13 years ago
Reassigning per Ben on IRC.  Ben also wants the extension icon issue (extensions
don't pick up any icon because icons are assigned based on window ID) fixed.
Assignee: rparenton → danm.moz
Status: ASSIGNED → NEW
Whiteboard: [ETA: As soon as icons arrive from Bugs 226599 and 242050] Attachment 147366, and Bugs 242598 & 242599 address "proper" way to fix (hackaround doesn't fix windows from extensions) → Bugs 242598 & 242599 address "proper" way to fix (hackaround doesn't fix windows from extensions)

Comment 125

13 years ago
Is this in any way related to Bug 249246 ?

Comment 126

13 years ago
(In reply to comment #125)
> Is this in any way related to Bug 249246 ?

No.

Updated

13 years ago
Flags: blocking-aviary1.0RC1?
Flags: blocking-aviary1.0RC1? → blocking-aviary1.0RC1-
*** Bug 253223 has been marked as a duplicate of this bug. ***

Comment 128

13 years ago
*** Bug 254046 has been marked as a duplicate of this bug. ***

Comment 129

13 years ago
*** Bug 245966 has been marked as a duplicate of this bug. ***

Comment 130

13 years ago
Installing a new icon set will cause the icon to set itself properly (win98, the
problem doesn't exist on win2k and winxp).

http://iconpacks.mozdev.org/packs/firefox-experimental.html

Obviously, you get the new icons you've just installed, rather than the proper
firefox icon. But it's better than the windows one.

Comment 131

13 years ago
*** Bug 259269 has been marked as a duplicate of this bug. ***
*** Bug 260596 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Flags: blocking0.9-
Flags: blocking0.8-
Flags: blocking-aviary1.0+ → blocking-aviary1.0-

Comment 133

13 years ago
Please consider just doing a workaround fix for 1.0, just place an icon into the
appropriate directory and this'll fix the bug for the vast majority of users. At
least it'll show the correct icon on win98 for the main window even if it
doesn't for extensions.

It's no risk and a whole lot better than nothing.
Flags: blocking-aviary1.0- → blocking-aviary1.0?

Comment 134

13 years ago
That was already considered and rejected. There are lots of much more
significant bugs that have got pushed off the blocker list, so I don't see any
reason to think they'll change their minds on this one.
Flags: blocking-aviary1.0? → blocking-aviary1.0-

Comment 135

13 years ago
because the fix is simple and the bug makes firefox look terribly unprofessional?

Comment 136

13 years ago
Go ahead and renominate if you want - I won't take it off again. This bug
doesn't look any worse than it did when they rejected the nomination the first
time, and there are already more than 60 bugs nominated as blockers, and many of
them are more significant than this. Actually I can't see them having the time
to even process the nominations, so it may all be academic anyway...

Updated

13 years ago
Flags: blocking-aviary1.0- → blocking-aviary1.0?

Updated

13 years ago
Flags: blocking-aviary1.0? → blocking-aviary1.0-

Comment 137

13 years ago
I use windows me and right now my firefox 1.0rc2 use the default windows icon.
Personally, I think this bug should be fixed before the official 1.0 release: it
gives people a extremely negative impression about the quality of firefox 1.0
(they will think this software is pre-alpha and no one will deploy it. It's the
same idea as a job interview: first impression counts the most) Besides, the
workaround is very simple and we had fixed most of the important bugs.
Flags: blocking-aviary1.0- → blocking-aviary1.0+

Comment 138

13 years ago
Yaun Qi, only developers / drivers can mark a bug as blocking1.0+
Flags: blocking-aviary1.0+

Comment 139

13 years ago
Back to the original blocking-aviary1.0-
Flags: blocking-aviary1.0-

Comment 140

13 years ago
I agree with Yuan Qi that having this bug unfixed makes it look bad as an
official release... With the official release out and all the publicity it's
getting, more and more people are going to be downloading Firefox, and there are
still plenty of people who use Win9x. I've resorted to extracting the icon from
the exe, putting it on my web server, and pointing everyone in the forum who
asks about this problem to download them and place them in the
chrome\icons\default folder. If no other fix can easily be done, couldn't the
installation just put the appropriate icons into this folder? (And perhaps as an
added step, only do this if Win9x is detected?)

Comment 141

13 years ago
Target Milestone: Firefox1.1?
*** Bug 270131 has been marked as a duplicate of this bug. ***

Comment 143

13 years ago
My icons for the Firefox toolbar are not displaying correctly. They appear as
calendar icons. Anyone have any fix for this issue?

Thank you, 

kuthumi.shiva@verizon.net
*** Bug 272741 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Assignee: danm.moz → nobody
Target Milestone: Firefox1.0beta → ---

Updated

13 years ago
Flags: blocking-aviary1.1?
*** Bug 277609 has been marked as a duplicate of this bug. ***

Comment 146

13 years ago
excuse me for asking, but why has it been over two years for a bug with such an
easy work around not to be fixed yet?? i install ff 1.0 on win98 machines almost
on a daily basis, and it not having a proper icon makes it look terribly
unprofessional. this should have been fixed way before 1.0 (it has been around
since 0.2!!), since it hasn't this should be a definate blocker for 1.1!

it's just rediculous a great program like this still doesn't have a proper
window icon even two months after release!

Updated

13 years ago
Blocks: 163993

Comment 147

13 years ago
It seems to work in WinXP Pro but it didn't work in Win98.
Can anyone confirm?

Comment 148

13 years ago
This was confirmed a long time ago.  Did you read the comments?

Comment 149

13 years ago
I've created what I hope is a fix:
http://iconpacks.mozdev.org/packs/firefox-win98-fix.html

Comment 150

13 years ago
(In reply to comment #149)
> I've created what I hope is a fix:
> http://iconpacks.mozdev.org/packs/firefox-win98-fix.html

This fix works perfectly to amend this bug on Windows 9x.

Comment 151

13 years ago
(In reply to comment #150)
> (In reply to comment #149)
> > I've created what I hope is a fix:
> > http://iconpacks.mozdev.org/packs/firefox-win98-fix.html
> 
> This fix works perfectly to amend this bug on Windows 9x.

I confirm this fix the bug.

Comment 152

13 years ago
(In reply to comment #150)
> (In reply to comment #149)
> > I've created what I hope is a fix:
> > http://iconpacks.mozdev.org/packs/firefox-win98-fix.html
> 
> This fix works perfectly to amend this bug on Windows 9x.

It fixes the icon for the main window and the Downloads window, but it does not
fix several other child windows. It should also contain icons for the following:

bookmark-window.ico
jsconsoleWindow.ico
extensionsManager.ico
themesManager.ico
metadata.ico < for "Properties" window.
help.ico <-Help window
winInspectorMain.ico (for DOM Inspector)

chatzilla-window.ico <for ChatZilla extension
adblockPreferencesWindow.ico (for adblock extension)
preferential.ico (for preferential extension)
amazWindow.ico (for MAB extension) 

This list was taken from this mozillazine post:
http://forums.mozillazine.org/viewtopic.php?p=977988#977988

Comment 153

13 years ago
(In reply to comment #152)
>It fixes the icon for the main window and the Downloads window, but it does not
>fix several other child windows. It should also contain icons for the
>following:

>themesManager.ico

In my tests, themesManager.ico doesn't replace Firefox's theme window icon, and
I can't figure out what name should. Does anybody know?
FWIW, I see this with:  Windows Me, firefox 1.0, with no previous firefox
installs or profiles.
Created attachment 174886 [details]
screen shot of firefox 1.0 on Windows ME

Comment 156

12 years ago
A number of Internet Cafes around Asia still seem to be using Windows 98. From
my experience even the latest release of Firefox 1.0 still has the icon problem.
It affects both the taskbar icon and the window icon. Maybe simply a question of
a slight API difference somewhere?

Note: Had I been back home I would have said that "Windows 98" didn't matter
anymore, but going around internet cafe shows me otherwise.

Comment 157

12 years ago
Although Eweek's comments are as provincially US-oriented as talk about "back
home" by the previous poster probably are (Firefox and the Internet are
international phenomena!), the following figures are interesting and probably
internationally representative:

http://www.eweek.com/article2/0,4149,1436854,00.asp
January 12, 2004
Ottawa-based AssetMetrix Inc.'s Research Labs found that more than 80 percent of
companies surveyed still run Windows 98 and/or Windows 95 computers in their
business or enterprise.

IDC, of Framingham, Mass., estimates that 58 million users still run Windows 98
and that 21 million users still run Windows 95. 

http://www.microsoftmonitor.com/archives/002080.html
Jupiter Research data shows that plenty of U.S. households still run Windows 98,
98 SE or Me.

Comment 158

12 years ago
http://www.shtcc.net/04%20jAN%20B.pdf
January 2004
As an additional
note, in January our Club will start using Windows
XP in our Basic Computer Class, replacing Windows
98. Analysis of our Club data indicates that about
30% of our users still run Windows 98, and about 12%
use Windows ME. We still have a few Windows 95 users.
Nationally, about 20 percent of all computers still
run Windows 95 or 98, according to technology market
research firm International Data Corp. 

Comment 159

12 years ago
Really, I think that the default behavior should be to set windows to the
application's default icon if the icon files in chrome/icons/default aren't
there.  If they aren't, the current behavior is to do nothing.  Happily, this
goes unnoticed on newer operating systems, but it should still be changed.  I
might think about trying to come up with a patch.

Comment 160

12 years ago
*** Bug 278066 has been marked as a duplicate of this bug. ***

Comment 161

12 years ago
Excuse me, but I'm new here. I voted recently for this bug. In fact it was the
main reason I registered. 
This bug was first discovered about 2 1/2 years ago and is still listed as
"NEW"? And under Target Milestone there is no entry - just dashes. Doesn't sound
too encouraging to me. 
As I understand it, there has been no activity in solving this rather small bug,
other than workarounds involving editing configuration files and manually adding
the icons to Firefox folders. (Or installing a different theme?) The average new
user can't be expected to do these things. The problem seems trivial to solve
and makes a pretty poor impression on would-be converts. Even two-bit "hacker"
programs for video editing, etc. manage to get their icons in the Windows
taskbar! Then again, I don't know much about coding.
At any rate, I think a "real" fix definitely should have been included in the
1.0 release and should now at least be included for the upcoming 1.1 release. Is
that doable? Comments?

Comment 162

12 years ago
re comment #6, I filed bug 284962 against thunderbird (firefox doesn't have the
problem any more on Linux)

Comment 163

12 years ago
Comment #159, see Bug 242599, as that would be the best place for your work.

Comment #162, the problem does not exist in official Linux builds because they
are now GTK2 build, but the problem still exists in GTK1 builds.

Comment 164

12 years ago
*** Bug 259634 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Depends on: 111111

Comment 165

12 years ago
> This bug was first discovered about 2 1/2 years ago and is still listed as
> "NEW"?

Mozilla, like all the other big projects, has a LOT of bureuacracy going on. I
reported this so long ago I forgot all about it, and probably would've submitted
it again if it weren't for the recent activity of my report being marked as a
dupe... But even if it requires 5 people to check it and give it their OK,
surely adding a .ico to the package can't be /that/ hard, can it?

Updated

12 years ago
No longer depends on: 111111

Comment 166

12 years ago
Thunderbird has an icon, so why doesn't Firefox?

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1

Updated

12 years ago
No longer depends on: 242599

Updated

12 years ago
Depends on: 242599

Comment 167

12 years ago
I am not a programmer but I opened Firefox.exe in Resource Tuner to look at the
built-in resources and they were there **BUT** Resource Tuner showed the label
"<BAD ID> 1912" under the directory heading of "Group Icons" along with a
listing labeled "1" and a third listing labeled "32512". The actual icons are
all there in another directory which these listings refer to the correct icon
index of, far as I can tell. The problem apparently must be with the ID for the
first group of icons under "Group Icons". This does not look like a Windows bug
so much as a goof in the resource packaging.

Just my two cents' worth. Firefox v1.0.2 Windows 98.

Updated

12 years ago
Flags: blocking-aviary1.1? → blocking-aviary1.1+
Whiteboard: Bugs 242598 & 242599 address "proper" way to fix (hackaround doesn't fix windows from extensions) → Bugs 242598 & 242599 address "proper" way to fix (hackaround doesn't fix windows from extensions) [asaP1]

Comment 168

12 years ago
(In reply to comment #167)
> I am not a programmer but I opened Firefox.exe in Resource Tuner to look at the
> built-in resources and they were there **BUT** Resource Tuner showed the label
> "<BAD ID> 1912" under the directory heading of "Group Icons" along with a
> listing labeled "1" and a third listing labeled "32512". The actual icons are
> all there in another directory which these listings refer to the correct icon
> index of, far as I can tell. The problem apparently must be with the ID for the
> first group of icons under "Group Icons". This does not look like a Windows bug
> so much as a goof in the resource packaging.
> 
> Just my two cents' worth. Firefox v1.0.2 Windows 98.
Yeah, good point, Alan!

I checked several apps with PE Resource Explorer, there are no icon which id is
'0'. ZoneAlarm's app icon is '1' and most apps are '100' and above, so I think
in Win9x app icon's id should not to be '0'.

Comment 169

12 years ago
Created attachment 180128 [details] [diff] [review]
patch for Windows, change icons' id 1-origin. 

Does anyone make a test build with this patch?

Comment 170

12 years ago
(In reply to comment #169)
> Created an attachment (id=180128) [edit]
> patch for Windows, change icons' id 1-origin. 
> 
> Does anyone make a test build with this patch?

Way to go Anbo!!
Sounds like you're on the right track.

I think you meant: "CAN anyone make a test build with this patch?"
I'm not that smart, but maybe if you post the question in the firefofox builds
forum, someone there might be able to help. Or better yet, do a search in the
forums for instructions or a FAQ on making your own build. I know there is one
somewhere. It's open source after all. 

This all sounds like an act of desperation, but if it works, what the heck.
Good luck!

Comment 171

12 years ago
Comment on attachment 180128 [details] [diff] [review]
patch for Windows, change icons' id 1-origin. 

This doesn't work. Sorry for bug spams.
Attachment #180128 - Attachment is obsolete: true

Comment 172

12 years ago
This comment is for only Win9x, not for Linux.

Finally, I found that this bug is regression of bug 9449. It changes icon
reference API from LoadIcon to LoadIconW, but LoadIconW doesn't exist in Win9x.
So on Win9x application icon is default one.

Old:
wc.hIcon            = ::LoadIcon(::GetModuleHandle(NULL), IDI_APPLICATION);
New:
wc.hIcon            = ::LoadIconW(::GetModuleHandle(NULL),
MAKEINTRESOURCEW(IDI_APPLICATION));

In this case, is Unicode support needed? My understanding is Unicode support is
for I18N-ed path name and/or I18N-ed ID.
Is this correct?

Patch follows...

Comment 173

12 years ago
Created attachment 180473 [details] [diff] [review]
actual patch for win9x
Attachment #180473 - Flags: review?

Comment 174

12 years ago
Comment on attachment 180473 [details] [diff] [review]
actual patch for win9x

No, this is not the way to go. Perhaps, for now, LoadIcon has to be handled the
way SendMessage and other APIs are handled in nsToolkit. I'll make a patch
soon.
Attachment #180473 - Flags: review? → review-

Comment 175

12 years ago
Created attachment 180548 [details] [diff] [review]
fix LoadIcon invocation

I'm not sure if this will fix the problem on Win 9x/ME. If Motohiko-san is
right about the cause of the problem on Win 9x/ME, this should fix the problem
there. (I don't understand why this doesn't cause the same problem for suite,
though). I'll test it on Win ME later (after building a 'dist' build which will
take some time), but if somebody can test it on Win ME, that'll be nice.
Motohiko-san, can you test my patch on Win 9x/ME?

Comment 176

12 years ago
Comment on attachment 180548 [details] [diff] [review]
fix LoadIcon invocation

Asking for r/sr.

I tested it on Win ME and worked fine.

I'll add a comment explaining why it's safe to cast aIconNameW to LPCSTR
without any charset conversion.
Attachment #180548 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #180548 - Flags: review?(timeless)
Comment on attachment 180548 [details] [diff] [review]
fix LoadIcon invocation

A simple test shows me that platforms that support LoadIconW return the same
integer resource icon that they do for LoadIconA. So I go for the previous
patch.
Attachment #180548 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview-
Comment on attachment 180473 [details] [diff] [review]
actual patch for win9x

Although you might want to comment that you use LoadIconA because there's no
unicode issues with loading integer icons.

Comment 179

12 years ago
(In reply to comment #177)
> (From update of attachment 180548 [details] [diff] [review] [edit])
> A simple test shows me that platforms that support LoadIconW return the same
> integer resource icon that they do for LoadIconA. 

That's what I expected to get when it works. What I had in mind is that
LoadIconA may fail altogether when firefox is installed in a path whose name
isn't representable in the current code page (for A APIs). (it may not fail in
such a case depending on how it's implemented internally, but there's no way to
know that without experimenting)  However, this should be a non-issue because in
that case perhaps firefox won't be able to start in the first place (until bug
162361 is fixed), which I didn't consider when making the patch. So, for now, I
agree that we should go with the previous patch with a comment like this: 

XXX : There's no point using 'W' API until bug 162361 is fixed. 

 

Updated

12 years ago
Attachment #180548 - Flags: review?(timeless)

Updated

12 years ago
Attachment #180473 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #180473 - Flags: review-
Attachment #180473 - Flags: review+
Comment on attachment 180473 [details] [diff] [review]
actual patch for win9x

I don't see what effect that should have, resources are loaded by module
handle.
Attachment #180473 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview+

Comment 181

12 years ago
(In reply to comment #180)
> (From update of attachment 180473 [details] [diff] [review] [edit])
> I don't see what effect that should have, resources are loaded by module
> handle.

Needless to say, Unicode file I/O doesn't affect LoadIcon at all. However, I
guess LoadIconA and LoadIconW would make a difference when our icon file is in
the path whose name is not covered by the current code page for A APIs. (I can't
be 100% sure because I don't know how they're implemented by MS) Because Unicdoe
file I/O doesn't work (so that we can't access other files critical to us even
before we  load icons), currently there's no point making LoadIcon Unicode-safe. 

Comment 182

12 years ago
Created attachment 180574 [details] [diff] [review]
patch for checkin

OK, I added a comment addressed in comment #179 and request approval.
Attachment #180574 - Flags: approval-aviary1.1a?

Comment 183

12 years ago
Created attachment 180576 [details] [diff] [review]
and patch for aviary branch

For aviary branch. Mostly same as attachment #180574 [details] [diff] [review], no comment.

This bug is minor 'polish' thing, but many users got annoyance about this.
Please, please consider check this also in for Aviary Branch!
Attachment #180576 - Flags: approval-aviary1.0.3?

Comment 184

12 years ago
Comment on attachment 180473 [details] [diff] [review]
actual patch for win9x

I apologize for checking in without approval to 1.1a (I thought aviary tree was
not frozen, but that didn't make sense because suite and aviary share this
code).

Anyway, I'm seeking for a (retroactively). This  is a very low risk patch, but
would please Win 9x/ME users. The patch author already asked for approval for
checking in a virtually identical patch to 1.0.3 branch so that I'm not asking
for a1.0.3 here.
Attachment #180473 - Flags: approval-aviary1.1a?

Comment 185

12 years ago
Comment on attachment 180473 [details] [diff] [review]
actual patch for win9x

a=asa (retroactive) for checkin to the trunk.
Attachment #180473 - Flags: approval-aviary1.1a? → approval-aviary1.1a+

Updated

12 years ago
Attachment #180574 - Attachment is obsolete: true
Attachment #180574 - Flags: approval-aviary1.1a?

Comment 186

12 years ago
Then, GTK1 issue is left. I'm not Linux user, this comment is FYI.

In GTK2's nsWindow.cpp, NativeCreate() calls SetDefaultIcon() to set
'default.xpm' for app icon.
http://lxr.mozilla.org/mozilla/source/widget/src/gtk2/nsWindow.cpp#2293

But GTK1, this code is missing.
http://lxr.mozilla.org/mozilla/source/widget/src/gtk/nsWindow.cpp#1832

Should be like this?
1865     mIsToplevel = PR_TRUE;
         SetIcon(NS_LITERAL_STRING("default"));
1866     mShell = gtk_window_new(GTK_WINDOW_DIALOG);
  :
1920     mIsToplevel = PR_TRUE;
         SetIcon(NS_LITERAL_STRING("default"));
1921     mShell = gtk_window_new(GTK_WINDOW_TOPLEVEL);


And there are no codes for GTK1's icons in makefile.
http://lxr.mozilla.org/mozilla/source/browser/app/Makefile.in#252


Does anyone try to fix this?

Comment 187

12 years ago
Comment on attachment 180576 [details] [diff] [review]
and patch for aviary branch

OK, now 1.0.3 is shipped, ask for 1.0.4...
Attachment #180576 - Flags: approval-aviary1.0.3? → approval-aviary1.0.4?

Updated

12 years ago
Flags: blocking-aviary1.0.4?

Comment 188

12 years ago
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050417 Firefox/1.0+

Recent Fx-trunk did not show this bug on Win98SE. Seems fixed! Thanks.

Comment 189

12 years ago
Before the patch will be implemented in an official Firefox release, you can use
Icon Restorer at: <a
href="http://iconpacks.mozdev.org/packs/remove-restore.html">http://iconpacks.mozdev.org/packs/remove-restore.html</a>

Comment 190

12 years ago
Before the patch will be implemented in an official Firefox release, you can use
Icon Restorer at: http://iconpacks.mozdev.org/packs/remove-restore.html

Comment 191

12 years ago
(In reply to comment #190)
this was already noted before in comments #149~153.
Comment on attachment 180576 [details] [diff] [review]
and patch for aviary branch

this isn't a security fix or a regression from a security fix.	We're limiting
checkins on the branch now, and this doesn't meeet the criteria

Comment 193

12 years ago
(In reply to comment #192)
> (From update of attachment 180576 [details] [diff] [review] [edit])
> this isn't a security fix or a regression from a security fix.
> We're limiting
> checkins on the branch now, and this doesn't meeet the criteria
> 
Accoding to Asa's announcement, there are chances for non-security issues.
http://www.mozillazine.org/articles/article6312.html
> If you've got a patch that isn't security related and which you believe is an
absolute must-have on the Mozilla 1.7 and Aviary 1.0 branches, please contact
drivers...

mconnor, if you are one of the drivers, please deny my requests. I've asked
drivers about this bug the other day, and I'm waiting for the answer...

Comment 194

12 years ago
All the graphics on the Browser are gone.  It displays graphics on the web
pages, but the back and foreward, file, edit, and other tabs are just text now.
 This happened when i applied the Brushed theme onto the browser, which is
strange because brushed worked fine before.

Comment 195

12 years ago
(In reply to comment #194)
> All the graphics on the Browser are gone.  It displays graphics on the web
> pages, but the back and foreward, file, edit, and other tabs are just text now.
>  This happened when i applied the Brushed theme onto the browser, which is
> strange because brushed worked fine before.

That has absolutely nothing to do with this bug.

Comment 196

12 years ago
Can someone with proper bugzilla rights mark this as Fixed?  From reading the
comments, it appears a fix was checked into the trunk some time ago.

Comment 197

12 years ago
(In reply to comment #196)
> Can someone with proper bugzilla rights mark this as Fixed?  From reading the
> comments, it appears a fix was checked into the trunk some time ago.

No.  This is not fixed on GTK1 builds.

Updated

12 years ago
Whiteboard: Bugs 242598 & 242599 address "proper" way to fix (hackaround doesn't fix windows from extensions) [asaP1] → Not fixed on GTK1 (See Bug 242599 for what needs to be done) [asaP1]

Updated

12 years ago
No longer blocks: 163993

Updated

12 years ago
Blocks: 164421
Marking as fixed to get off 1.1 radar.  Please use bug 242598 for the remaining
GTK1 issue. GTK1 is not an officially supported platform at this time (and
hasn't been for well over a year now), so that isn't going to block 1.1. 
comment 186 has some useful info for someone interested in fixing this for that
platform.
Status: NEW → RESOLVED
Last Resolved: 14 years ago12 years ago
Resolution: --- → FIXED

Updated

12 years ago
Whiteboard: Not fixed on GTK1 (See Bug 242599 for what needs to be done) [asaP1] → Not fixed on GTK1 (See Bug 242598 for what needs to be done) [asaP1]
not blocking a 1.0.5 security release
Flags: blocking-aviary1.0.5? → blocking-aviary1.0.5-

Comment 200

12 years ago
Today I made a fresh install of Firefox 1.0.5 on Win98 system. I was a bit
embarresed to see the "MS application icon" there... 
Wasn't this bug fixed? Or is it fixed but the patch will be included only in 1.1?

Comment 201

12 years ago
>Wasn't this bug fixed? Or is it fixed but the patch will be included only in 1.1?

The latter, see Comment 199

Comment 202

12 years ago
*** Bug 301906 has been marked as a duplicate of this bug. ***

Comment 203

12 years ago
Comment on attachment 180576 [details] [diff] [review]
and patch for aviary branch

1.0.5 has already shipped; removing approval request.
Attachment #180576 - Flags: approval-aviary1.0.5?
*** Bug 304317 has been marked as a duplicate of this bug. ***

Comment 205

12 years ago
ENV: WinXP / Firefox 1.5
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Verified resolved.

Comment 206

9 years ago
(In reply to comment #205)
> ENV: WinXP / Firefox 1.5
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111
> Firefox/1.5
> Verified resolved.
> 
Was it verified in Win 98?

Comment 207

9 years ago
(In reply to comment #206)
> (In reply to comment #205)
> > ENV: WinXP / Firefox 1.5
> > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111
> > Firefox/1.5
> > Verified resolved.
> > 
> Was it verified in Win 98?
> 
It was fixed for Firefox 1.5 so all Win95/Win98/ME users that got the Windows flag icon on Firefox 1.0.x and earlier have had a Firefox main-window icon ever since Firefox 1.5 (1.0.x never got the patch as per #187). The upcoming Firefox 3.0 will not run on Win95/98/ME/NT4 so kind of moot there...
You need to log in before you can comment on or make changes to this bug.