Closed Bug 171349 Opened 22 years ago Closed 19 years ago

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

Categories

(Firefox :: General, defect, P2)

x86
All
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: Biesinger, Unassigned)

References

Details

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

Attachments

(8 files, 9 obsolete files)

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
jshin1987
: review+
Details | Diff | Splinter Review
6.38 KB, patch
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)

*** This bug has been marked as a duplicate of 170677 ***
Status: NEW → RESOLVED
Closed: 22 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 → ---
This actually happens on Linux too - in KDE I just get the default X icon.
OS: Windows 98 → All
Summary: phoenix icon is standard windows icon → Phoenix icon is windowing system's standard icon
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...
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.
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?
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)
*** Bug 184298 has been marked as a duplicate of this bug. ***
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)
*** Bug 185100 has been marked as a duplicate of this bug. ***
Attached image 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.
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.
*** Bug 192183 has been marked as a duplicate of this bug. ***
*** Bug 193124 has been marked as a duplicate of this bug. ***
*** 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.  
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.)
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.

*** This bug has been marked as a duplicate of 170677 ***
Status: NEW → RESOLVED
Closed: 22 years ago21 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. :-)
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
Closed: 21 years ago21 years ago
Resolution: --- → WORKSFORME
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.
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.
*** Bug 214631 has been marked as a duplicate of this bug. ***
bug 214631 says win98 only and uses recent build so I'm reopening for the minority
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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.
Attached image screenshot under linux
Icons under Linux for window/taskbar
I think it's just win98 that has it
*** Bug 215525 has been marked as a duplicate of this bug. ***
*** Bug 218095 has been marked as a duplicate of this bug. ***
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?
Attached image Screenshot under WinME
The attached image shows Firebird as it currently displays under WindowsME.
QA Contact: asa
*** Bug 220841 has been marked as a duplicate of this bug. ***
*** Bug 223659 has been marked as a duplicate of this bug. ***
*** Bug 224682 has been marked as a duplicate of this bug. ***
*** Bug 211525 has been marked as a duplicate of this bug. ***
*** Bug 221439 has been marked as a duplicate of this bug. ***
Flags: blocking0.8?
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.
I see this bug on the non-XFT build of Firebird.  Noticed when using Firebird
0.7 on KDE 3.1 under Debian Linux
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.
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
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.
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
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?
I guess it's worse than that: Win98 doesn't do well on anything other than 16 
colours... (unless I'm confused with Win95)
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.
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)
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 #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)
(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.)
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
*** Bug 236412 has been marked as a duplicate of this bug. ***
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.
As I recall, its jsconsolewindow.xpm not jsconsoleWindow.xpm (note the lack of
capitalisation). Does this work for you?
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
*** Bug 239150 has been marked as a duplicate of this bug. ***
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?
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?
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-
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?
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.
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.
Attachment #146999 - Attachment mime type: application/octet-stream → image/x-icon
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
Status: NEW → ASSIGNED
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...
Attached image Non-branded icon without 32-bit icons (obsolete) —
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.
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
I still see the default Windows icon. Using rparenton's build with an old profile.
Flags: blocking1.0?
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.
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.
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? :-)
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 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
Attachment #147083 - Attachment is obsolete: true
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.
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.
(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.
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.
Attached patch Patch for Unbranded Icons Only (obsolete) — Splinter Review
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
Blocks: 241905
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
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.
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.
Attachment #147185 - Attachment is obsolete: true
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)
(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.

Sorry - wrong Antony!
(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?
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 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)
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
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.
(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...
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.
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.
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
*** Bug 239993 has been marked as a duplicate of this bug. ***
-> 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 → ---
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+
Blocks: 233462
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.
Whiteboard: See comment #106 for a summary of what needs to be done to fix properly
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)
Depends on: 242598
Depends on: 242599
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)
Depends on: 242050
Depends on: 226599
Depends on: 242598
Assignee: firefox → rparenton
Severity: minor → normal
Depends on: 242599
Target Milestone: --- → Firefox1.0beta
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
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)
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 #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.
*** Bug 245069 has been marked as a duplicate of this bug. ***
Attachment #147366 - Attachment is obsolete: true
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.
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?
(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.
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.
(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.
(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.
I get this problem on my Win98 machine, but my WinXP box is fine. I even ran
from the same installer exe!
*** Bug 249427 has been marked as a duplicate of this bug. ***
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)
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)
Is this in any way related to Bug 249246 ?
(In reply to comment #125)
> Is this in any way related to Bug 249246 ?

No.
Flags: blocking-aviary1.0RC1?
Flags: blocking-aviary1.0RC1? → blocking-aviary1.0RC1-
*** Bug 253223 has been marked as a duplicate of this bug. ***
*** Bug 254046 has been marked as a duplicate of this bug. ***
*** Bug 245966 has been marked as a duplicate of this bug. ***
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.
*** Bug 259269 has been marked as a duplicate of this bug. ***
*** Bug 260596 has been marked as a duplicate of this bug. ***
Flags: blocking0.9-
Flags: blocking0.8-
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
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?
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-
because the fix is simple and the bug makes firefox look terribly unprofessional?
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...
Flags: blocking-aviary1.0- → blocking-aviary1.0?
Flags: blocking-aviary1.0? → blocking-aviary1.0-
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+
Yaun Qi, only developers / drivers can mark a bug as blocking1.0+
Flags: blocking-aviary1.0+
Back to the original blocking-aviary1.0-
Flags: blocking-aviary1.0-
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?)
Target Milestone: Firefox1.1?
*** Bug 270131 has been marked as a duplicate of this bug. ***
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. ***
Assignee: danm.moz → nobody
Target Milestone: Firefox1.0beta → ---
Flags: blocking-aviary1.1?
*** Bug 277609 has been marked as a duplicate of this bug. ***
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!
Blocks: majorbugs
It seems to work in WinXP Pro but it didn't work in Win98.
Can anyone confirm?
This was confirmed a long time ago.  Did you read the comments?
I've created what I hope is a fix:
http://iconpacks.mozdev.org/packs/firefox-win98-fix.html
(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.
(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.
(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
(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.
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.
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.
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. 
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.
*** Bug 278066 has been marked as a duplicate of this bug. ***
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?
re comment #6, I filed bug 284962 against thunderbird (firefox doesn't have the
problem any more on Linux)
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.
*** Bug 259634 has been marked as a duplicate of this bug. ***
Depends on: 111111
> 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?
No longer depends on: 111111
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
No longer depends on: 242599
Depends on: 242599
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.
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]
(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'.
Does anyone make a test build with this patch?
(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 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
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...
Attachment #180473 - Flags: review?
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-
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 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.
(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. 

 

Attachment #180548 - Flags: review?(timeless)
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+
(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. 

Attached patch patch for checkin (obsolete) — Splinter Review
OK, I added a comment addressed in comment #179 and request approval.
Attachment #180574 - Flags: approval-aviary1.1a?
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 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 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+
Attachment #180574 - Attachment is obsolete: true
Attachment #180574 - Flags: approval-aviary1.1a?
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 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?
Flags: blocking-aviary1.0.4?
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.
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>
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
(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
(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...
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.
(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.
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.
(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.
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]
No longer blocks: majorbugs
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
Closed: 21 years ago19 years ago
Resolution: --- → FIXED
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-
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?
>Wasn't this bug fixed? Or is it fixed but the patch will be included only in 1.1?

The latter, see Comment 199
*** Bug 301906 has been marked as a duplicate of this bug. ***
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. ***
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.
(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?

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