70126 - F9 to open Sidebar does not restore sidebar width

Status: VERIFIED WORKSFORME

(SeaMonkey :: Sidebar, enhancement, P2)

Description

[ajbu]

used: Windows 2000, build 2001021508
Using the mouse, you can click on the sidebar sizer to 'minimize' the sidebar
(it is still visible buth with a zero width.), and click on it again to
'restore' the sidebar to its previous size. Using the keyboard you can turn the
sidebar on/off, but can not restore/set the width.

When

- Open the sidebar
- Click on the sizer to minimize the sidebar
- Toggle the sidebar away with F9

Expected result: Turning the sidebar on with F9 should set the sidebar to the
default size or the size last used for the expanded state.
Alternative would be to have a shortcut key to collaps the sidebar.

Comment 1

[timeless]

please don't file dupes.

Comment 2

[Jesse Ruderman]

Timeless: that comment wasn't helpful (like many of your comments on new 
bugs).  I don't think this is a duplicate of an existing bug.

Comment 3

[timeless]

erm, sorry, I track bugs by mail and received too many notifications about this 
bug [not sure why] that i started thinking this bug was not the original

Comment 4

[Alec Flett]

reassign to sidebar owner

Comment 5

[Håkan Waara]

WORKSFORME in 20010302.

Can anyone else try to reproduce this and confirm it in a comment or resolve as WFM?

Comment 6

[Jesse Ruderman]

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

Comment 7

[Samir Gehani]

Open to default width rather than collapsed?  

Comment 8

[matt]

Attachment: patch for hidden window to uncollapse on unhidding.

Comment 9

[matt]

Behavior w/ patch
collapse sidebar
hide sidebar F9/or menu
unhide sidebar F9/ or menu
sidebar opens uncollapsed to last opened width.

If the sidebar is uncollaspsed then it will open to last known width.

Need reviews

Comment 10

[sujay]

Rearranging the code in SidebarSelectPanel() would be more consistent cause with
this patch the only client function -- SidebarSelectPanel() -- is also calling
SidebarExpandCollapse() as soon as it returns from SidebarShowHide(). 
(Interlace the checks determining action with the actions themselves, i.e., move
line 755 after line 747.)  

Comment 11

[Samir Gehani]

Last comment was from me (Sujay was logged into my machine).

Comment 12

[Aaron Leventhal]

This is a good start.

Using the patch, I found that when the sidebar is collapsed, but not hidden,
pressing F9 hides it. The next time you press F9 it finally opens fully. 

It takes 2 presses F9 to see it again. This is an improvement, but I don't think
it's right yet. When the sidebar is not visible to the user, the first F9 should
open it fully. When it's collapsed, why would a user want to hide it.

Question: why are there 3 states instead of two anyway? I want to see it or not
see it, not have 2 ways of hiding it. Isn't that likely confusing to many users?

Comment 13

[Samir Gehani]

German, 
Would you like to address the need for hidden vs. collapsed sidebar: a question
posed by Aaron?  Thanks.

Comment 14

[Jesse Ruderman]

The reason for the collapsed state is so mouse users can find the sidebar again 
after closing it.  Keyboard and menu users prefer to have the sidebar actually 
go away when they tell it to go away.  (The same argument could also be made 
for collapsable toolbars, but I think there should be a separate mode or window 
for rearranging toolbars, and no UI to move them in a normal browser window.  
The toolbar grippies take up valuable space on the left edge of the screen and 
they're easy to click accidentally.)

Comment 15

[Samir Gehani]

Should be addressed by sidebar usability improvement effort.

Comment 16

[Samir Gehani]

-> mozilla0.9.8

Comment 17

[Samir Gehani]

Sidebar triage team: WORKSFORME now.

Comment 18

[sujay]

verified.