67110 - Add ability for adding Icon to Sidebar tabs

Status: RESOLVED EXPIRED

(SeaMonkey :: Sidebar, enhancement)

Description

[Viswanath Ramachandran]

Today, you define a new panel by calling a JS function to put it in the sidebar.
 This function takes a panel name/description and an URL as parameters.  It
should take another URL that specifies an icon image.  The sidebar then has to
use that information to properly display the icon at the side of the tab's
title. The icon must fit within certain sizing guidelines.

Comment 1

[Matthew T (active 1999-2002)]

This could be done just as for any other Web page, with <link rel="icon"
href="http://foo.bar/hum/icon.png"/>. However, that particular method would not 
be possible for sidebar panels which are not HTML.

Comment 2

[selmer (gone)]

mpt, would that show up in the TAB portion of the sidebar?

Comment 3

[Matthew T (active 1999-2002)]

If someone implemented it that way, yes.

Comment 4

[german]

Older Netscape Aurora designs (predating open source) had an icon only view 
like minimized tabs. 
The largest challenge in my mind is to evangelize developers to add 
branding/icons to their sidebar panels. After all, non-Netscape panels add to 
the attractiveness of sidebar as a truly personal space.
It isn't much help if you have a generic icon for every panel. Other than that 
an iconized view is a good thing IMO. 
Reported IE6 sightings have seen a similar design, albeit there seemed to 
experiment with a gigantic tooltip that was extending the icon view to include 
the full title text of all panels on mouseover which is not a bad idea.

It will be important to set guidelines on the allowed size/height and enforce 
them by scaling or cropping the images to avoid unusable stretching of panels. 
14px height might be a good value to get started. Thoughts?

Comment 5

[kmurray1115]

It would be great to see this in action to see if it's something we want to
pursue. Is there anyone that has created an example of this to date? Anyone?
hint hint ;-)

Comment 6

[german]

BTW to digress I suggest we also use this as bookmarks/page proxy icons when 
they are saved as well as when the available panels are displayed in the 
sidebar customize dialog. (Rather than the not useful generic bookmark which 
needs to be removed see bug 44016)

Comment 7

[Paul Chen]

Nice, but I'm not sure we have time in beta timeframe to do this. Marking nsbeta1-

Comment 8

[kmurray1115]

Paul, let's discuss these before we minus them outright. I would expect you and 
I to triage first.

Comment 9

[Paul Chen]

Removing nsbeta1-, need to retriage

Comment 10

[Samir Gehani]

Taking.  

Comment 11

[Richard Klein]

I would like to see this.  the icon could replace the arrow in the classic skin.
 I think would be awesome if you could have the sidebar minimized to an Icon
view.  Click on the icon and the sidebar slides out then have the sidebar auto
retract or be able to pin it in place.

Comment 12

[Samir Gehani]

I have the code working to conditionally show an icon next to the tab title
(i.e., if specified in the panel list).  Now I need some icons to include in the
product.  Filed bugzilla bug 107685 for the mozilla icons and bugscape bug 10814
for the netscape icons.

Comment 13

[Samir Gehani]

Plan on landing early in mozilla0.9.7.

Comment 14

[Samir Gehani]

-> mozilla0.9.8

Comment 15

[Joe Hewitt (gone)]

we should just use favicons or link icons (like mpt said) for this, rather than
devising some new scheme to store an icon url in the sidebar rdf.

Comment 16

[Samir Gehani]

Joe, 
Andrew mentioned the concept of latching onto favicons here.  However, for
chrome tabs we will need to do some extra work anyways (like mpt realized).  So
my plan is as follows:

(1) for chrome tabs:
  (a) look for the icon in the sidebar rdf

(2) for html tabs:
  (a) look for the <link rel="icon">
  (b) fallback to the favicon if it exists
  (c) fallback to the icon in the sidebar rdf if it exists

Of course, no icon will appear if neither favicon nor a sidebar rdf specified
icon is supplied.

Comment 17

[Peter Trudelle]

Don't have time for this until all committed MachV work is done.
->mozilla1.0.1/helpwanted.

Comment 18

[andreww]

I want to help implement this - should I reassign it to myself and get the 
files you already have samir?

Comment 19

[Samir Gehani]

Andrew, 
You are welcome to take this over and assign the bug to yourself if you have the
cycles.  I can mail you the patch if you'd like and explain what I have already?

Comment 20

[andreww]

taking - please email me what you have so far.

Comment 21

[Samir Gehani]

Attachment: Minimal sidebarOver.xul patch to support icons specified in the panels.rdf datasource.

Comment 22

[Jaime Rodriguez, Jr.]

This bug is targetted for M101. Should we remove it from blocking Bug 102472,
since its current target is outside the dev window for the next release?

Comment 23

[Samir Gehani]

The mozilla1.0.1 milestone was left over from when it was still assigned to me.
 Reinitializing miletsone for andreww to target per his schedule.

Comment 24

[Lori Kaplan]

Holding off on approval waiting for results of performance investigation. Won't
implement if there's too much of a hit to page load time from including the
icons. Andrew is investigating. 

Comment 25

[Lori Kaplan]

Not going to make it in this release. Futuring so we can keep this on the radar. 

Comment 26

[Peter Trudelle]

Moving to 1.2 parking lot with other late cuts, removing from my tracking bug.

Comment 27

[Ian Pottinger]

adding self to cc list

Comment 28

[Alex Hirzel]

Dup of bug 113574?

Comment 29

[Robert Kaiser]

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

Comment 30

[Robert Kaiser]

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

Comment 31

[Robert Kaiser]

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

Comment 32

[Robert Kaiser]

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

Comment 33

[Robert Kaiser]

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

Comment 34

[Robert Kaiser]

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

Comment 35

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420