Closed Bug 89144 Opened 19 years ago Closed 18 years ago

Need keyboard access to "Tabs" menu in sidebar

Categories

(SeaMonkey :: Sidebar, defect, P2, major)

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0.1

People

(Reporter: aaronlev, Assigned: andreww)

References

(Blocks 1 open bug)

Details

(Keywords: access, Whiteboard: [ADT2 rtm][ue wanted][fixed in trunk & branch])

Attachments

(1 file, 1 obsolete file)

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.
Keywords: access
Summary: Need keyboard access to "Tabs" menu in sidebar → Need keyboard access to "Tabs" menu in sidebar
Blocks: 89148
sounds like we need to talk about this first. 
i'm open to
view>
toolbars
-
sidebars

if people are opposed to that then good :-)
Assignee: matt → mpt
Component: Sidebar → User Interface Design
QA Contact: sujay → zach
mpt, are you okay with timeless's suggestion?
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}
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.
P2 for 0.9.7
Priority: -- → P2
Target Milestone: --- → mozilla0.9.7
Keywords: nsbeta1
We need to move on this one. This is a Section 508 issue.

-> Trudelle, for triage
Assignee: mpt → trudelle
Keywords: fcc508
If we ship with any such menu. ->sgehani, nsbeta1+/1.0
Keywords: nsbeta1nsbeta1+
Target Milestone: mozilla0.9.7 → mozilla1.0
->sidebar
Assignee: trudelle → sgehani
Component: User Interface Design → Sidebar
QA Contact: zach → sujay
Reassigning 'several bugs at once' to Steve Morse, to level the load better
across the team.
Assignee: sgehani → morse
ADT2 per ADT triage team
Whiteboard: [ADT2]
We can't move on this one without an agreed-upon spec.  Reassignig to Marlon to 
come up with a spec for this.
Assignee: morse → marlon
This is one of our most glaring section 508 holes.
Severity: normal → major
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.
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.  
Note to self: 
http://lxr.mozilla.org/seamonkey/source/xpfe/components/sidebar/resourc﷒0
Assignee: marlon → andreww
Whiteboard: [ADT2] → [ADT2 rtm]
Target Milestone: mozilla1.0 → mozilla1.0.1
Status: NEW → ASSIGNED
Whiteboard: [ADT2 rtm] → [ADT2 rtm][ue wanted]
Attached patch patch v1 (obsolete) — Splinter Review
patch ready for review.
Whiteboard: [ADT2 rtm][ue wanted] → [ADT2 rtm][ue wanted][need r/sr]
Attached patch patch v2Splinter Review
updated patch. Dont need to explicitly set focus: rule
Attachment #85347 - Attachment is obsolete: true
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 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.
Attachment #85356 - Flags: review+
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.




or blake, he's on the nav team and nav owns sidebar, right?
Comment on attachment 85356 [details] [diff] [review]
patch v2

sr=hewitt
Attachment #85356 - Flags: superreview+
Comment on attachment 85356 [details] [diff] [review]
patch v2

r=sgehani
Fixed in trunk
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Keywords: adt1.0.0
Resolution: --- → FIXED
Whiteboard: [ADT2 rtm][ue wanted][need r/sr] → [ADT2 rtm][ue wanted][fixed in trunk]
adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch, pending
Driver's approval.
Blocks: 143047
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.
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
belatedly mailing drivers now.
Status: REOPENED → ASSIGNED
Attachment #85356 - Flags: approval+
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1"
keyword and add the "fixed1.0.1" keyword.
fixed in branch - leaving open for post rtm/1.0 fixing during sidebar 
redesign.
Keywords: fixed1.0.1
Whiteboard: [ADT2 rtm][ue wanted][fixed in trunk] → [ADT2 rtm][ue wanted][fixed in trunk & branch]
Keywords: mozilla1.0.1+
If this bug is fixed, then please mark it RESOLVED-FIXED.
Marking this fixed, I've filed bug 149678 to track a cleaner/better way to fix.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago18 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
Keywords: verified1.0.1
Keywords: fixed1.0.1
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.