25459 - XUL Buttons need to take (and indicate) focus

Status: RESOLVED FIXED

(Core :: XUL, defect, P3)

Description

[Nathan Kirkham]

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.

Comment 1

[Sean Richardson]

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.

Comment 2

[Stephen P. Morse]

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.

Comment 3

[don]

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

Comment 4

[Ben Goodger (use ben at mozilla dot org for email)]

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. 

Comment 5

[sairuh (rarely reading bugmail)]

passing this to eli...

Comment 6

[Peter Trudelle]

reassigning to evaughan

Comment 7

[Eli Goldberg]

Moving to XPApps.

Comment 8

[Eric Vaughan]

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?

Comment 9

[Jim Roskind]

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

Comment 10

[german]

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.

Comment 11

[german]

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

Comment 12

[Ben Goodger (use ben at mozilla dot org for email)]

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. 

Comment 13

[don]

Move to M20 target milestone.

Comment 14

[Ben Goodger (use ben at mozilla dot org for email)]

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. 

Comment 15

[Ben Goodger (use ben at mozilla dot org for email)]

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

Comment 16

[Blake Ross]

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

Comment 17

[Matthew T (active 1999-2002)]

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.

Comment 18

[Peter Trudelle]

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.

Comment 19

[Matthew T (active 1999-2002)]

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!

Comment 20

[Peter Trudelle]

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'? 

Comment 21

[Matthew T (active 1999-2002)]

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.

Comment 22

[Peter Trudelle]

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.

Comment 23

[Ben Goodger (use ben at mozilla dot org for email)]

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.

Comment 24

[Peter Trudelle]

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

Comment 25

[Matthew T (active 1999-2002)]

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.

Comment 26

[Peter Trudelle]

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.

Comment 27

[Paul Chen]

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

Comment 28

[shrirang khanzode]

cc :jrgm

Comment 29

[Ben Goodger (use ben at mozilla dot org for email)]

now fixed in the classic skin.

Comment 30

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/50f6448c8ab9
[fenix] For https://github.com/mozilla-mobile/fenix/issues/25459 - Show Pocket sponsored stories irrespective of topics selections