allow user to navigate panes+frames using keyboard only

VERIFIED FIXED in mozilla0.9.1

Status

()

defect
P1
major
VERIFIED FIXED
20 years ago
2 months ago

People

(Reporter: xiaotong, Assigned: rods)

Tracking

(Blocks 1 bug, {access, helpwanted})

Trunk
mozilla0.9.1
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: ETA mm/dd?; need for embedding 0.9, )

Attachments

(3 attachments)

Reporter

Description

20 years ago
This is opened to address priority 1 item according to W3C accessibility
guildline. Checkpoint 7.1 - allow user to navigate viewports (including frames).
Currently it's almost impossible to navigate between frames without using mouse.
It should be done in a device independent manner, e.g., user should be able to
do it using keyboard only.
Reporter

Updated

20 years ago
Blocks: uaag

Comment 1

20 years ago
same as #24413, reassign it to lake to find proper eng. to reassign. We will 
need to figure out the engineering resource for futuer commitment. UI team can't 
implement anything.
Assignee: shuang → lake

Comment 2

20 years ago
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
Ctrl+Tab! Ctrl+Tab! :-)

Comment 4

19 years ago
QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs 
to Matthew Thomas (mpt@mailandnews.com).

Matthew Thomas is now the QA owner for the User Interface: Design Feedback 
component. (Bugs that involve UI issues in the Netscape-branded Mozilla browser 
should continue be QA assigned to elig@netscape.com.)
QA Contact: elig → mpt

Comment 5

19 years ago
Nominating for Beta 2. This may not seem like a big deal but it is escential 
that we have full keyboard functionality.
Keywords: nsbeta2
Priority: P3 → P1

Comment 6

19 years ago
Putting on [nsbeta2-] radar for beta2.   Would not hold beta2 for this, but I am 
adding to the nsbeta3 keyword to make sure it gets in for PR3.
Keywords: nsbeta3
Whiteboard: [nsbeta2-]
> - Additional Comments From Matthew Thomas 2000-04-13 04:17 -
>
> Ctrl+Tab! Ctrl+Tab! :-)

I agree; Ctrl+Tab is the best way to solve this. Ctrl+Shift+Tab should also work (backwards).

In some programs (i.e. MS Word) Ctrl+(Shift+)F6 is also used. Might be a good idea of this would work too (isn't Ctrl+Tab used in Composer (though Composer doesn't support frames ...)?).
Karl: See bug 30864 for the Ctrl+Tab tragicomedy.

Updated

19 years ago
Keywords: access

Comment 9

19 years ago
marking nsbeta3- while lake has this bug.
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3-]

Comment 10

19 years ago
Lake isn't here anymore. Who should this bug be assigned to?
Does anyone have an idea how it would be done?
We need to fix this asap.

Comment 11

19 years ago
Paul, is someone else handling bugs assigned to Lake?  We need this for 
accessibility, very high priority.
Chaning the qa contact on these bugs to me. MPT will be moving to the 
owner of this component shortly. I would like to thank him for all his hard 
work as he moves roles in mozilla.org...Yada, Yada, Yada...
QA Contact: mpt → zach

Comment 13

19 years ago
=>hangas per trudelle
jesse says we might dupe this on a ctrl-tab bug
Assignee: lake → hangas
Keywords: nsbeta2, nsbeta3qawanted
OS: Windows NT → All
Hardware: PC → All
Whiteboard: [nsbeta2-][nsbeta3-] → DUPEME?

Comment 14

19 years ago
slight misunderstanding.  I didn't say to reassign; just that Paul owns any bugs
assigned to Lake (as her manager).  We do need to get this correctly assigned
though.

Comment 15

19 years ago
Paul,

Do you have any ideas for this one? We need to find someone to own this, it's a
crucial fix at the moment. Let me know what I can do to help.

Aaron

Comment 16

19 years ago
cc german in hopes he can help with this.

Comment 17

19 years ago
we'll bring this up in the next accessibility meeting
updating to new owner. sorry for the spam.
Assignee: hangas → mpt

Comment 19

18 years ago
The keyboard team has put up a spec at:
http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html
We sometimes meet on Fridays. Let us know if you want to get involved.

We decided to be consistent with Internet Explorer for frame navigation with the
keyboard.

In Internet Explorer, Ctrl+(Shift)+Tab and (Shift)+F6 are both ways of
navigating through the frameset. We should implement these combos for all
platforms. On Mac OS, implement Cmd+(Shift)+Tab in place of Ctrl+(Shift)+Tab
[Cmd is "meta" in the code]. Some Mac OS users remap their switch app command
away from Cmd+Tab; they'll be able to take advantage of Cmd+Tab for frame
navigation.

The frame navigation keyboard command must also cycle through the sidebar, the
URL bar, and any other panes in the app (in mailnews for example). (This is also
similar to IE).
Keywords: nsbeta1

Comment 20

18 years ago
Note: the redundancy of having both the above methods implemented for keyboard
frame nav will get around the problem of OS's taking the keystrokes away from us.

Updated

18 years ago
Blocks: 70229

Updated

18 years ago
Severity: normal → blocker
Keywords: qawantedhelpwanted
QA Contact: zach → aaronl
Why was I de-qa'd from this bug?

Comment 22

18 years ago
Zach, it said qawanted in the keywords. Putting you back.
QA Contact: aaronl → zach
The qawanted is there for DUPEME, anyone interesting in trying to find a 
dup?
On Windows and X, use (Shift+)Control+Tab to switch between frames in cycle 
order. Also support (Shift+)F6 to

On Mac OS, use (Shift+)Control+Tab (*not* (Shift+)Command+Tab, otherwise you'll 
collide with the OS) to switch between frames in cycle order. Do *not* support 
(Shift+)F6 as well, or you'll collide with what the user has assigned to F6.

Everybody happy? --> Keyboard Navigation ...
Assignee: mpt → alecf
Component: User Interface: Design Feedback → Keyboard Navigation
QA Contact: zach → sairuh
Whiteboard: DUPEME?
> Also support (Shift+)F6 to

... to maintain compatibility with other Windows apps. [Sorry about that.]

Comment 26

18 years ago
Aw heck. Looks like we should have talked about this on Moz Accessibility too 
Aaron. 

Matthew... lets talk about this in the mailing list rather than spam this bug. We 
had reasons I hope you'll agree with for what Aaron posted.

Updated

18 years ago
Summary: allow user to navigate frames using keyboard only → allow user to navigate panes+frames using keyboard only

Comment 27

18 years ago
*** Bug 30864 has been marked as a duplicate of this bug. ***

Comment 28

18 years ago
<pasted together from Matt's two posts>

"Also support (Shift+)F6 to maintain compatibility with other Windows apps.  On 
Mac OS .. Do *not* support (Shift+)F6 as well, or you'll collide with what the 
user has assigned to F6."

I wouldn't call F6 compatible with any Windows apps other than IE.  The 
standard for switching between MDI document windows was originally F6.  Then, 
when MS realized that was a very awkward shortcut, they introduced Ctrl+Tab.  
Somewhere along the way, they thought that F6 was now available for other 
functions.  F6 is dumb.  [Shift+]Ctrl+Tab is all we should support.  I don't 
know one user, even the power-user programmers that I work with, that have ever 
used F6 to navigate in or between windows.  Save F6 for something else.

Comment 29

18 years ago
i've only used ctrl-f6 [ie not plain f6] for mdi navigation. However, I use it 
in most wordperfect suite apps as well as borland resource workshop.

ctrl-tab in a composer and similar apps to do pane switching will mess things 
up.

I think we could use f6 to navigate among chrome objects (sidebar, location, 
browser:content). 

Comment 30

18 years ago
Yep, we knew this would be a hard one to pin down!
Okay, I've spoken with mpt, timeless and dean_tessman.

At least for PC and Unix, everyone's okay with Ctrl+(Shift)+Tab and (Shift)+F6 now.

I'm a little unclear on the ideal Mac OS behavior here. Would mpt, brade and
lordpixel please huddel and decide whether you want Cmd or Ctrl Tab, or both,
and whether it's okay to have the F6 binding there. We're pretty close to making
this a platform independant binding.

So, we're ready to go ahead with implementation for Windows & Unix. We'll add
Mac bindings when we get the design decision. 

Target locked. Fire phasers.

Comment 31

18 years ago
Reassigning to aaronl since he seems to be the one driving this bus.
Assignee: alecf → aaronl
Sorry, I thought I'd written this earlier ... I've talked with lordpixel and 
brade about the Mac binding, and both agreed with my 2001-03-15 comment. So for 
Mac, it is (Shift+)Control+Tab, and not (Shift+)F6.

Updated

18 years ago
Severity: blocker → major

Comment 33

18 years ago
->moz0.9.1
Target Milestone: --- → mozilla0.9.1
Assignee

Comment 34

18 years ago
I seems like maybe Chris Saari has a bug like this.

Comment 35

18 years ago
Chris is not around to do this, can you help with it Rod?  Whoever gets it,
please add an ETA MM/DD in the status whiteboard ASAP. 
Whiteboard: need for embedding 0.9

Updated

18 years ago
Blocks: 75785

Updated

18 years ago
Whiteboard: need for embedding 0.9 → ETA mm/dd?; need for embedding 0.9

Comment 36

18 years ago
Rod is working on this.
Assignee: aaronl → rods

Updated

18 years ago
Blocks: 65632
Assignee

Comment 38

18 years ago

Comment 39

18 years ago
Any particular reason why you have SetHasFocus as a method instead of a hasFocus
attribute?

Comment 40

18 years ago
Can you explain ScrollPositionWillChange in the canvas frame?  I just want to 
make sure you didn't have to disable all blitting on Web page scrolls because 
the focus border is being drawn.

Also, do you draw this rect even on mouse focus, or do you only start showing 
it when the user tabs? IE only shows a ring when the user starts tabbing.

Comment 41

18 years ago
> IE only shows a ring when the user starts tabbing.

This is only true in NT (the OS's native UI behaves the same way).  9x shows it 
in response to the mouse also.
Assignee

Comment 42

18 years ago
Saari, I don't quite understand your question, hasFocus is an attribute in the 
IDL. Chris, if you meant the opposite of what you wrote, I made it an attr for 
no other reason then I get a setter/getter out of it and whether a docshell has 
focus does seem to be an attr-like thing.

Hyatt, the canvas frame is a scroll listener so it remove the focus ring when 
you start scrolling. Basically, it sets the bool to false that enables the 
drawing and then it makes sure the entire is painted so the ring is removed, 
because scrolling only invalidates the portion of the view that scrolls into 
view.

If desired, I don't think it would be hard at all to have the focus ring show up 
for a mouse click. I see that Win2000 does NOT show it on the click.
Status: NEW → ASSIGNED
Assignee

Comment 43

18 years ago
Also, I needed to add this bit of code at the top of SetHasFocus, so only 
content children will ever get a focus ring:


NS_IMETHODIMP
nsDocShell::SetHasFocus(PRBool aHasFocus)
{
  if (mParent != nsnull) {
    PRInt32 type;
    mParent->GetItemType(&type);
    if (type != nsIDocShellTreeItem::typeContent) {
      return NS_OK;
    }
  }

Comment 44

18 years ago
Ok, looks good to me. sr=hyatt

Comment 45

18 years ago
Look okay to me.  Just make sure to test

1) Tab navigation through mail compose windows
2) Tab navigation through preferences dialogs
3) Basic tab/tabindex behavior

As long as those all still work, r=joki

Comment 47

18 years ago
wow, impressive patch. r=saari but you should definitely sych up with bryner on
this.
Assignee

Comment 48

18 years ago
This bug was for the initial work for getting it to work. it has been checked. 
Currently, <shift>tab and <ctrl><shift>tab do not work because the key events 
are not being properly sent (there is already an open bug on this).

Navigating backwards still has some issues, I wil check with Bryner to see if 
there is an open bug for this or whether one needs to be opened.

F6 now works but gets hung up in the sidebar, there is already a bug for this.

Please do not re-open this bug for any reason, please file new bugs.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
thx for checking this in, rod.

since shift+tab and ctrl+shift+tab don't currently work [could someone let me
know that the bug number is for that?], what are the keyboard shortcut[s] that
would work so that i could verify this? f6 and shift+f6? just wanted be clear, thx!
Assignee

Comment 50

18 years ago
The <ctrl> tab issue is part of Bug 50255

F6 and <shift>F6 should work.
vrfy fixed using f6 and shift+f6 in the browser. tested using 2001.05.23.08 on
linux and 2001.05.24.0x on mac and winnt. filed the following:

bug 82656: frames cycle momentarily loses focus
bug 82650: [rfe] f6 goes ccw, shift+f6 clockwise

nbaca, could you check how this works for you in mailnews? if it's basically
okay, go ahead and mark this verified (and file others for new/separate issues
:). thx!
QA Contact: sairuh → nbaca

Comment 52

18 years ago
Build 2001-05-25-04: WinMe
Build 2001-05-25-08: Linux RH 6.2
Build 2001-05-25-05: Mac 9.04
Verified Fixed. The basics are working in Mail and I will log separate bugs on 
specific issues found.
Status: RESOLVED → VERIFIED
Component: Keyboard: Navigation → User events and focus handling
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.