82.49 KB, image/png
825 bytes, image/png
8.08 KB, image/png
17.06 KB, image/png
9.00 KB, image/jpeg
1008 bytes, patch
|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: 17 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. ***
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: 17 years ago → 16 years ago
Resolution: --- → DUPLICATE
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: 16 years ago → 16 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 firstname.lastname@example.org 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.
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?
The attached image shows Firebird as it currently displays under WindowsME.
*** 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. ***
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.
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=18.104.22.168&rev2=22.214.171.124&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.
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.
*** Bug 236412 has been marked as a duplicate of this bug. ***
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.
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:email@example.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
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...
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:firstname.lastname@example.org/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.
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
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.
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
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:email@example.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.
Comment on attachment 147206 [details] [diff] [review] Patch for Branded & Unbranded Cases (GTK+ Only) Brian, can you take a look at these GTK+ changes.
(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!
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?
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.
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
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
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+
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)
Assignee: firefox → rparenton
Severity: minor → normal
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. ***
Priority: -- → P2
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 ?
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: 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...
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+
Back to the original 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, firstname.lastname@example.org
*** Bug 272741 has been marked as a duplicate of this bug. ***
*** 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!
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. ***
> 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?
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
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)  > 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...
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.
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] ) > 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.
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] ) > 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.
OK, I added a comment addressed in comment #179 and request approval.
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+
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?
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] ) > 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]
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: 16 years ago → 14 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.