Closed Bug 82130 Opened 23 years ago Closed 15 years ago

Favicon on the taskbar / task manager (title bar)

Categories

(SeaMonkey :: UI Design, enhancement)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: tomee, Assigned: jag+mozilla)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: platform-parity) 

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 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
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.
Severity: trivial → enhancement
Status: RESOLVED → UNCONFIRMED
Component: User Interface Design → XP Apps: GUI Features
Depends on: 32087, 36305
Keywords: pp
Resolution: DUPLICATE → ---
Assignee: mpt → blakeross
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: zach → sairuh
--> default owners
QA Contact: sairuh → claudius
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?
Status: NEW → ASSIGNED
Target Milestone: --- → Future
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)
Keywords: mozilla1.2
OS: Linux → All
Hardware: PC → All
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
Depends on: 109037
bug 112383 asks for favicon in the taskbar
bug 120352 is a general tracking bug for favicons
Blocks: 120352
Depends on: 112383
-> hyatt
Assignee: blaker → hyatt
Status: ASSIGNED → NEW
Summary: Icon on the taskbar / task manager → Favicon on the taskbar / task manager
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. ***
Keywords: mozilla1.2
Product: Core → Mozilla Application Suite
*** 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)
Depends on: 38447
Summary: Favicon on the taskbar / task manager → Favicon on the taskbar / task manager (title bar)
Component: XP Apps: GUI Features → UI Design
Assignee: hyatt → jag
QA Contact: claudius
Target Milestone: Future → ---
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
Status: NEW → UNCONFIRMED
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.
Status: UNCONFIRMED → NEW
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.
Status: NEW → RESOLVED
Closed: 23 years ago → 15 years ago
Resolution: --- → WONTFIX
See Also: → 558300
You need to log in before you can comment on or make changes to this bug.