Hey, this one has been bothering me for a while. Konqueror for Linux does support those nifty ca. 16x16 icons some pages include, and it shows them in the taskbar, in the URL bar and in other places. Why can't mozilla? Most big sites have an icon (like CNET, GOOGLE) and having it displayed on the taskbar makes finding the right window much much easier. So, why wasn't this included?

*** This bug has been marked as a duplicate of 32087 ***

Dependent, but not a dup. Support for custom page icons alone would not fix this. In the absence of a non-XP Apps: GUI component, sending to XP Apps: GUI.

--> default owners

Bug 32087 is for it being displayed in the URL bar, since that is about the favicon implementation. I do not believe the application icon should be changed on the application window, since people will see the URL bar's icon. I do believe, though that the taskbar should have the icon changed, as this WILL as you said make finding the window easier. Should we make a windows, mac, etc version of this bug, or should we assign this to all operating systems?

I actually like the sound of this. ATM I don't like the fact that all mozilla windows (nav, mail/news, composer, etc) have the same icon and will like the day when I can distinguish mail from the browser just by looking at the app icon. This takes it a step further by being able to distinguish various webpages just by looking at the taskbar. I wouldn't say this bug depends on bug 36305, because I'm personally against that bug being 'fixed' on win32, because I'm used to the standard mouse behaviour of win32 apps (see rant in other bug)

Don't know if this is a related issue or not: Should there be different taskbar icons for mail/news vs. a browser windows? Using Favicons is a GoodThing[tm], but the basic distinction between mail/browsing should aready be implimented no?

Support for distinctive icons is already available, just we don't have separate icons checked into the tree just yet. You can install the icons manually yourself: http://www.consultanddesign.com/mozilla/ (that only works in Windows I've not looked into icons for Linux/X11 and don't have a mac) Another Mozilla based application that has separate icons for mail, composer, etc is Netscape 6.1/6.2

bug 112383 asks for favicon in the taskbar bug 120352 is a general tracking bug for favicons

-> hyatt

I'm worried that allowing a site to choose its titlebar icon would make it possible for a site to completely spoof a Mozilla or system dialog. On the other hand, I think this would be a very cool feature. I suggest we enable this only for browser windows that have full chrome (all the user's toolbars, etc). By the way, this bug conflicts with bug 16213, which would use a subtle change in the window icon to indicate when a page is finished loading in a background window. But since I'd mostly use bug 16213 to tell when something has loaded in a new window (rather than an existing window in which I had clicked a link), it should be possible to support both. Or it might not be necessary to support both, if every page in the new windows has an icon.

Jesse: Hmmm. Wouldn't it be obvious its a spoof by the title of the window? It still might be nice to change the icon on a simple window. Perhaps Mozilla could compare the icon to its current icon and if within a certain range, warn the person that it might be an attempted spoof?

> Wouldn't it be obvious its a spoof by the title of the window? A site can push the " - Mozilla {...}" off of the title bar using space characters, so that check isn't foolproof. See also bug 56995, "Application name should not be included in window title". > Perhaps Mozilla could compare the icon to its current icon A site might also try to spoof a system dialog, and Mozilla doesn't know what all system dialogs look like.

I think there sould be at least separate icons for mail, composer, browser. so that you can see in the taskbar which bottom is for which application. the same symbols like in the window menu would be fine. how it is now, it is not a problem to work - but it looks a little unfinished. espacialy for version 1.0.

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

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

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

with the patches from bug 38447, this should be really easy to implement, at least on windows and gtk2 (http://developer.gimp.org/api/2.0/gtk/GtkWindow.html#gtk-window-set-icon for the latter, with the imgIContainer->pixmap conversion function that's already in the tree)

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

Still valid on Seamonkey 2.0a3. This is still worth implementing.

We have no plans of implementing this in SeaMonkey itself, feel free to create and add-on that does this if you want that feature.