89144 - Need keyboard access to "Tabs" menu in sidebar

Status: VERIFIED FIXED

(SeaMonkey :: Sidebar, defect, P2)

Description

[Aaron Leventhal]

We need to design a method for accessing the sidebar "Tabs" menu with the
keyboard. Keep in mind that Alt+F9 is going to focus the sidebar, Alt+PgUp/Dn
will move which tab is visible. If "My sidebar" was it's own tab - that would be
one way to deal with this. Barring that, I'm not sure how to elegantly deal with
this, in a way that's discoverable to the user.

Because of this I think the "Tabs" menu needs to be accessible from the main
menu bar.

Comment 1

[timeless]

sounds like we need to talk about this first. 
i'm open to
view>
toolbars
-
sidebars

if people are opposed to that then good :-)

Comment 2

[Aaron Leventhal]

mpt, are you okay with timeless's suggestion?

Comment 3

[Matthew T (active 1999-2002)]

Nope. The second item is the most highly visible item in any menu, and I don't 
think we should be wasting the second item in the `View' menu on a submenu of 
panels in something which will usually be closed.

Hmmm. Perhaps we could put it in the `Tools' menu.

Tools
-----
  Navigator
  Messenger
  Chatzilla
  Composer
-----------------------------
  Sidebar Tabs              >
-----------------------------
  {app-specific components}

Comment 4

[timeless]

erm, what i meant was to put the toolbars and tabs into the same submenu of the 
view menu.

I think I don't like the tools idea.

Comment 5

[Peter Trudelle]

P2 for 0.9.7

Comment 6

[Aaron Leventhal]

We need to move on this one. This is a Section 508 issue.

-> Trudelle, for triage

Comment 7

[Peter Trudelle]

If we ship with any such menu. ->sgehani, nsbeta1+/1.0

Comment 8

[Peter Trudelle]

->sidebar

Comment 9

[Peter Trudelle]

Reassigning 'several bugs at once' to Steve Morse, to level the load better
across the team.

Comment 10

[Peter Trudelle]

ADT2 per ADT triage team

Comment 11

[Stephen P. Morse]

We can't move on this one without an agreed-upon spec.  Reassignig to Marlon to 
come up with a spec for this.

Comment 12

[Aaron Leventhal]

This is one of our most glaring section 508 holes.

Comment 13

[andreww]

I'm willing to help implement this if I had a hint as to what was needed.  I'll
query Marlon tomorrow and see if we can come up something workable for the short
term.

Comment 14

[marlon bishop]

the tab 'purgatory' feature may be going away as soon as we can redesign
sidebar.  We attempted to do it in the current cycle but didn't have the time to
flesh out the ideas.  since we just need a quick fix why don't we add the tab
drop down menu to the Alt+PgUp/Dn selection order?  So when the user moves up
past the top tab they get the tab menu flyout.  

Comment 15

[andreww]

Note to self: 
http://lxr.mozilla.org/seamonkey/source/xpfe/components/sidebar/resourc﷒0﷓

Comment 16

[andreww]

Attachment: patch v1

patch ready for review.

Comment 17

[andreww]

Attachment: patch v2

updated patch. Dont need to explicitly set focus: rule

Comment 18

[Aaron Leventhal]

Comment on attachment 85356 [details] [diff] [review]
patch v2

r=aaronl
This -moz-user-focus override was necessary because the Tabs button is a
<toolbarbutton> which doesn't normally get focus.

Comment 19

[Aaron Leventhal]

Comment on attachment 85356 [details] [diff] [review]
patch v2

r=aaronl
This -moz-user-focus override was necessary because the Tabs button is a
<toolbarbutton> which doesn't normally get focus.

Comment 20

[(not reading, please use [e-mail] instead)]

coming up to speed on this one...

[Tabs V] is a toolbarbutton, type menu.

from
http://lxr.mozilla.org/seamonkey/source/xpfe/components/sidebar/resources/sidebarOverlay.xul#68

 68         <toolbarbutton type="menu" id="sidebar-panel-picker"
menubuttontype="sidebar-panels"
 69           onpopupshowing="SidebarBuildPickerPopup();"
 70           label="&sidebar.picker.label;" >
 
toolbarbuttons ignore focus, so that's why we can't tab to this one.
(the alternative to this would be to use another button, one that looked like a
button since [Tabs V] is a button.)

but that sounds outside the scope of this bug, and more into the land of the
sidebar redesign the marlon mentioned.

I'm ok with the change, but please add a comment to sidebar.css pointing back to
this sec508 bug.  (even though the cvs comment does that, someone will come
through, fix your whitespace or move your code around and then we'll forget why
it was added.)

also, please get module owner review.  (maybe samir or hewitt?)

sr=sspitzer once you add the comments and get module owner review.

Comment 21

[(not reading, please use [e-mail] instead)]

or blake, he's on the nav team and nav owns sidebar, right?

Comment 22

[Joe Hewitt (gone)]

Comment on attachment 85356 [details] [diff] [review]
patch v2

sr=hewitt

Comment 23

[Samir Gehani]

Comment on attachment 85356 [details] [diff] [review]
patch v2

r=sgehani

Comment 24

[andreww]

Fixed in trunk

Comment 25

[Jaime Rodriguez, Jr.]

adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch, pending
Driver's approval.

Comment 26

[[e-mail]]

Comment on attachment 85356 [details] [diff] [review]
patch v2

Nit: style could have gone into sidebarOverlay.css instead, as this is not a
theme-specific issue.

Comment 27

[Blake Ross]

This is certainly good enough to go on the branch, but it's not the right fix in
the long run.  This button should only take focus via the keyboard (just like in
IE).  I don't think that's currently possible to specify.  If it takes focus
with the mouse, then it's possible for it to have focus but not show it, and
focus should never disappear.

Comment 28

[andreww]

Sure, I agree.  It my understanding that sidebar is going to be undergoing 
a redesign (see samir) and dealing with this issue in a more 
comprehensive manner should be on the list of things to improve for that.

Comment 29

[andreww]

belatedly mailing drivers now.

Comment 30

[Judson Valeski]

please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1"
keyword and add the "fixed1.0.1" keyword.

Comment 31

[andreww]

fixed in branch - leaving open for post rtm/1.0 fixing during sidebar 
redesign.

Comment 32

[sujay]

If this bug is fixed, then please mark it RESOLVED-FIXED.

Comment 33

[Blake Ross]

Marking this fixed, I've filed bug 149678 to track a cleaner/better way to fix.

Comment 34

[sujay]

verified in 7/16 branch build.

However, I found a new bug which I filed:
http://bugzilla.mozilla.org/show_bug.cgi?id=157761

the caret doesnot go back and forth between browser and sidebar
when you do Alt-F9, especially in form field in search tab

Comment 35

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381