In other words, I should be able to close all the tabs.

this is a usability decision, assigning to german There is another bug written up that says clicking on the panel should reload it, so a decision has to be made.

to german

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

Cool, if the other bug says clicking should reload, then double clicking should close it. I've amended the summary, I hope that's OK.

spam: changing qa contact on sidebar bugs from paulmac to shrir@netscape.com (all 67 of them!)

Allowing a single click to close a sidebar is a very good idea. It would allow you to switch from one sidebar panel to another without having to go all the way from the top to the bottom of the sidebar (or vice versa); instead, you could just close the current sidebar panel by clicking in it, then all the panels would be at the top for you to choose from. Reloading a panel should be done by selecting the panel, and choosing Reload from the View menu or from the toolbar. (It should also be available from the panel's context menu, as for a normal Web page.)

Set to M18 for later polish since the basic feature is already there.

Agree with Matt, I think its a good idea and improves usability without changing the order of the tabs. Forwarding to slamm for help with implementation (the part about clicking on the header of an open panel should close it). Slamm if you do not have time pls let me know, then I'll ask for help.

If it's too hard to detect clicks in the header, perhaps you could have a little upwards pointing triangle in the header, (to the left of the title so ppl don't confuse it with the upwards scroll button) to indicate 'click here to close'.

To clarify: Clicking in the tab of the currently-open sidebar panel should close that sidebar panel, and open whichever one is at the bottom. That way all the sidebar panel tabs move to the top, but we're not left in a situation where we have no panel open at all (which would look seriously odd).

nominating nsbeta3

nav triage team: nice idea, but a new and unnecessary feature, too late for now. Might introduce complications (what happens when you click on the tab that is already the bottom tab, for example). nsbeta3- M Future to review later

Is it possible to have a standard context menu for all sidebar panels, that has standard menu items such as Reload, Close, etc? I have no idea, which is why I ask.

Reassigning 50 Sidebar bugs to Matt. I was told this was going to be done shortly about two months ago, but it clearly hasn't been. I think that's long enough for all these bugs to remain assigned to nobody. Feel free to filter all this spam into the trashcan by looking for this string in the message body: ducksgoquack

spam : changing qa to sujay (New Sidebar QA)

Am I the only one that thinks that this would be confusing (and annoying, if the user accidentally clicks on the header)? Why is it intuitive that clicking on the header when the panel is shown closes it? It seems to me that if clicking on the header were to do anything, it would just 'minimize' the header and go back to the one that was previously visible (just as buttons on the Windows taskbar and in mIRC's open windows toolbar work)

No, you're not alone, Blake! :-) Nevertheless I think that the more intuitive behavior would be to maximize the opened tab (maximize here means one tab in the sidebar). See the enhancement bug 79871 for the implementation of maximizing/minimizing of tabs.

Let's try to do this for mozilla0.9.7.

Moving to mozilla0.9.8.

Moving to milestone after mozilla0.9.9 (mozilla1.0 for now).

Sidebar triage team: -> Future, nsbeta1-

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

This bug will be invalidated if the current patch for bug 233874 is checked in.

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

(In reply to comment #23) > This bug will be invalidated if the current patch for bug 233874 is checked in. Its been 8 months, using 1.8.5 right now and still not added :( Any idea what's happening about getting this added or is holding my breath not advised? :)

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

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

Valid enhancement request.