Tabbing from the confirm the key control does not take you directly to OK. It stays where it is, then requires a number of tabs to appear on OK. CLick back on the confirm control, try again and a different amount of tabs is needed, or sometimes it won't appear on the OK.

This appears to be more a problem with the highlighting (dotting) of the [Ok] button than with the tabbing sequence. Tabbing from the "Confirm" control, the second TAB showed a caret in the "Password" control, and the third showed a caret back in the "Confirm" control, modulo 3. If <ENTER> was pressed at a time when the focus should have been on the [Ok] button, it continued to the next dialog as expected. But I never did get the [Ok] button to look different at any time. Tested with: 2000-01-28-12-M14 nightly binary on Windows NT 4.0sp3.

Although you are seeing this on a dialog used by single-signon, there is nothing unique to single singon here. This is a general dialog problem and is probably occuring on other dialogs as well. Assigning to Don.

Ben, is this our bug and is it fixable by beta 1?

if it is related to the :focus appearance of titledbuttons as sidr's comment suggests, then no, its not (yet) an XPApps issue. titledbuttons require the same internal rectangle for drawing the dotted focus indicator as html:button does. If this is available then I can rig up CSS to indicate focussed state.

passing this to eli...

reassigning to evaughan

Moving to XPApps.

Titledbuttons are exactly like html buttons they do have a inner focus rect. Its up to CSS whether you have one or not. Look at the rules for titledbuttons and html buttons. I'm suprised that titlebutton class="push" can't get focus. German shouldn't the rules be set up so they get focus?

This does not appear to be an M15 stability blocker... Moving to M16

This is windows only correct? I do not want to see something like this on a Mac. In fact Mac IE 5 has a nice notion of an outer focus rect on buttons not unlike what we are doing x-platform with text entry fields and not unlike something like WebTV. My opinion is that for a cross-platform look we should use these outer 2px focus rings for buttons as well. These make the current focus more easily discoverable.

also the proper component for this is XPToolkit. Changing subject to include buttons which are now the official successor of titledbuttons

titledbuttons are obsolete, resummarizing. button will receive a thin border similar to textfield for focus. currently button does not receive focus however so this is not an issue.

Move to M20 target milestone.

Windows buttons need to accept focus as that is the behaviour on windows. Need to create a platform stylesheet that implements this. Changing summary to reflect this. There is already code in the classic skin to display the focus rect.

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

Now that we no longer have those outer blue borders for textfields, is German's proposal (to provide similar borders for buttons) outdated? Focus rects are the standard on win32, so I suggest those. I don't understand why seemingly many of our UI decisions (e.g. File | Quit) are based around Mac ( < 3% marketshare) behavior. Updating summary, cc matthew thomas

Oi! I've been salivating over all the extra keyboard control I'm going to have with the Mac version of Mozilla (compared with 4.x), and now you want to take that away? Sorry, but that would violate section 2.1.4 of the W3C UAAGs (`Ensure that every functionality available through the user interface is also available through the standard keyboard API'). Buttons (and checkboxes, and radio buttons, and popup menus ...) should accept and indicate tab focus, whatever the platform. * On Windows, this should be shown with the usual little dotted rectangle. * On Mac OS and X, this should be shown with the lavender rectangle (copying the highlight pattern normally used for text fields, as German said earlier). - Where the default button (the one activated with the Enter key) has tab focus on Mac, the extra border of mid-gray piping should change to lavender. The above applies to the Classic skin. Presumably you don't want to develop platform-specific details for the Modern skin; so you'd either choose one of these highlight methods, or come up with something completely new.

Too bad about our not supporting that part of the UAAG, but then we don't support much of that proposed recommendation, nor do we claim to. Another quote from that document: "It is inappropriate to cite W3C Proposed Recommendations as other than 'work in progress'." As far as Mac tabbing goes, while most Mac apps have traditionally cycled between only the text fields (Chooser being an old exception), the Mac HIG does not forbid the Windows-like behavior, which is now supported in Office 98, although with poor discoverability. However, I'd tend to agree with german, and be cautious of introducing this on the Mac in the current release. It would be interesting to do, but I don't think we need to do it, nor do I think we have time to do it well.

Surely, even on a programming level, it would be much easier for widget tabbing to be implemented in the same way on all platforms -- rather than special-casing the Mac implementation in order to make Mac Mozilla *less* accessible!

Easier, probably, but then we'd have everyone up in arms about not being Mac-like. I don't have strong feelings about this, just wanted to point out that we don't have to support this, and that it may be non-trivial to do so while keeping expected Mac look/feel. Surely you don't want to make the product less usable for the vast majority of Mac users, just to more easily add support for those who are 'differently abled'?

I don't believe allowing non-text widgets to have focus will make Mozilla less usable for Mac users. The inability to do so in other Mac apps is one of the things that consistently annoys me about the Mac. (And that's not because I regularly use Windows; I don't.) YMMV, of course.

Allowing for it would fine if we had time, but adding them to the existing tabbing rotation would be a fundamental change to existing usage, one that we don't have to do. At this stage in the project, I recommend we avoid unnecessary risk.

we have a coherent tab rotation for dialogs? ;) I originally turned this on a while back but there were problems in editor that caused toolbar buttons to incorrectly steal focus. I think those were resolved however, and I'd like to cautiously move forward on this, on windows at any rate.

"I meant 'adding them to the tabbing expected on MacOS'", he said incoherently...

Would it help if I said `please'? :-) (If you don't, bags not being the person who has to go through all the XUL widgets, deciding which ones should accept focus on Mac OS and which ones shouldn't ...) Ben, toolbars should be able to specify whether they're interested in getting keyboard focus or not. For example the Location Toolbar in Navigator, and the Formatting Toolbar in Composer, would allow keyboard focus; but the Navigation Toolbar in Navigator, and the Command Toolbar in Composer, wouldn't. Then there would be two cycles: the cycle within the current frame/toolbar, and the cycle between frames/toolbars. Cycling between frames/toolbars (between the content frame(s) and the location bar in Navigator, for example) would be Ctrl+Tab/Ctrl+Shift+Tab, while cycling within the current frame/toolbar would be Tab/Shift+Tab.

There is already a bug 31809 about not being able to tab to the location toolbar. We decided that behavior was nsbeta3-, although help would be appreciated.

nav triage team: yeah, what Peter said. Could be an accessability problem for us, though. But for now, stays nsbeta3-

cc :jrgm

now fixed in the classic skin.