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.

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.

Moving all UE/UI bugs to new component: User Interface: Design Feedback UE/UI component will be deleted.

Ctrl+Tab! Ctrl+Tab! :-)

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.)

Nominating for Beta 2. This may not seem like a big deal but it is escential that we have full keyboard functionality.

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.

> - 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.

marking nsbeta3- while lake has this bug.

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.

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...

=>hangas per trudelle jesse says we might dupe this on a ctrl-tab bug

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.

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

cc german in hopes he can help with this.

we'll bring this up in the next accessibility meeting

updating to new owner. sorry for the spam.

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).

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.

Why was I de-qa'd from this bug?

Zach, it said qawanted in the keywords. Putting you back.

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 ...

> Also support (Shift+)F6 to ... to maintain compatibility with other Windows apps. [Sorry about that.]

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.

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

<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.

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).

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.

Reassigning to aaronl since he seems to be the one driving this bus.

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.

->moz0.9.1

I seems like maybe Chris Saari has a bug like this.

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.

Rod is working on this.

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

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.

> 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.

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.

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; } }

Ok, looks good to me. sr=hyatt

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

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

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.

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!

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!

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.