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.

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.

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

If someone implemented it that way, yes.

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?

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 ;-)

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)

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

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

Removing nsbeta1-, need to retriage

Taking.

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.

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.

Plan on landing early in mozilla0.9.7.

-> mozilla0.9.8

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.

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.

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

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

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?

taking - please email me what you have so far.

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?

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.

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.

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

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

adding self to cc list

Dup of bug 113574?

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

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