58853 - Dialog boxes should always get initial keyboard focus

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, enhancement, P3)

Description

[Aaron Leventhal]

When first entering a dialog box, there should always be an inital keyboard
focus.Right now you usually need to press TAB an extra time to get your focus
somewhere.

A side effect of there not being an initial focus, is that confirm/cancel
dialogs require TAB for space hits the OK button.

Comment 1

[Simon Lucy]

I'd put this higher than an enhancement, its a bug.

Comment 2

[Luis Villa]

It's not a dupe, but this is related to bug 54887, I think. 

Comment 3

[Jesse Ruderman]

See also bug 35087, dialog with one text field should set focus (programmers 
shouldn't have to manually set focus for each dialog).

Comment 4

[Viswanath Ramachandran]

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy

Comment 5

[Jesse Ruderman]

Blake just fixed this for dialogs that only have buttons (bug 63647).

Comment 6

[Blake Ross]

Not just with buttons. If it has a textfield, that gets focus first.  Only for 
common dialogs, though (alerts, etc.)

Comment 7

[Aaron Leventhal]

Okay, hopefully we're still going to make this the default behavior for any UI 
window that's opened, not just common dialogs.

Comment 8

[Chris McAfee]

nsbeta1

Comment 9

[Chris McAfee]

saari, aaron says he can help.

Comment 10

[Paul Chen]

nav triage team:

Marking nsbeta1+

Comment 11

[saari (gone)]

This is soo far off my radar for this release it isn't even funny. If you want
this fixed in that time frame, assign it to Aaron or someone else.

Comment 12

[Aaron Leventhal]

I should be able to handle this in a couple of weeks, when the XUL content 
model moves back into layout (Waterson's change). Hyatt and I were talking 
about leveraging the GetNextTabbableContent method in nsEventStateHandler, and 
exposing it in the XUL DOM through 
document.commandDispatcher.getNextTabbableContent(BOOL forward). 

I'd solve the problem as follows: in the XBL binding for <window 
class="dialog" ...> onload handler we check to see if the focus is already on a 
specific element (not the window as a whole). If it isn't, we move it to the 
first item using GetNextTabbableContent. If the first item is a tab widget, 
move it beyond the tab widget (this makes Ben Goodger happy). 

This solution works whether our onload handler gets called after the dialog's, 
or before it. If it gets called first, the window's handler still gets a chance 
to set focus. If it gets called after the window handler set a focus, we won't 
do anything because we check to see if the focus was already set. Therefore, we 
don't need to worry about the outcome of any bugs having to do with the order 
of onload event handling.

Comment 13

[sairuh (rarely reading bugmail)]

over to aaronl, if that be okay...

Comment 14

[David Hyatt]

I have implemented this in my tree.  jst and saari have reviewed.  aaronl, I can
take this bug off your hands if you want.

Comment 15

[Aaron Leventhal]

How'd you do it? Did you expose GetNextTabbableContent like we talked about?

Comment 16

[sairuh (rarely reading bugmail)]

i presume this bug covers the fact that the following dialogs don't have initial
focus set [if so, it goes hand in hand with bug 76814]:

Preferences
Account Settings
Customize Sidebar
Cookie Manager
Image Manager
Password Manager
both dialogs dealing with form data management

for me this is primarily a problem on linux and mac [not so much on win32].

Comment 17

[Matthew T (active 1999-2002)]

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

Comment 18

[jglick]

Add the Address Book, "Card for <name>" dialog to this list. Dup'd bug 82384.

1.Open the Address Book
2.Open an existing AB entry by either double clicking or using the Edit menu.
3."Card for <name>" dialog opens but nothing has focus.

Expected:
The first text field, "First" name should have focus.

Comment 19

[David Hyatt]

There is a method on the commandDIspatcher now that will do this.  If ben ever 
gets around to making a <dialog> binding, he should be able to build the focus 
advancement into the binding behavior.

Comment 20

[Matthew T (active 1999-2002)]

It shouldn't be specific to <dialog>s -- <window>s should have default focus set
too, though many of them will adjust the focus themselves.

Comment 21

[Aaron Leventhal]

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

Comment 22

[Mike Pinkerton (not reading bugmail)]

the lack of initial key focus for enter/esc (ok/cancel) in dialogs is 
embarrasing. why is this 1.1?

Comment 23

[saari (gone)]

It is 1.1 because dialog writers can set initial focus in onenddocumentload, and
because we don't want to go mucking around with focus and changing behavior
unless we really, really have to. Why, just this weekend the inital focus
screwed up rendering from jag's patch.

You're more than welcome to try and fix it if you want pink.

Comment 24

[Dan M]

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

Comment 25

[sairuh (rarely reading bugmail)]

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

Comment 26

[Aaron Leventhal]

Attachment: This seems to fix prefs, and probably anything that uses <dialog ... />

Comment 27

[Aaron Leventhal]

I'm guessing this patch works because it delays advanceFocusIntoSubtree() until
the the frame tree has been created.

It doesn't fix the account wizard, which doesn't seem to use either <dialog />
or <wizard />. In fact, nothing seems to use <wizard>, so I'm not sure why we
have wizard.xml at all.

Comment 28

[David Hyatt]

Yeah, that's right.  <wizard> is new, nobody is using it yet, but they should be. :)

sr=hyatt.  Feel free to take the bug, aaronl.

Comment 29

[Simon Fraser [no longer active]]

I checked in the patch to fix bug 103036.

Comment 30

[Aaron Leventhal]

I can't mark this fixed because it doesn't seem to fix all windows, only those
created with <dialog>

Comment 31

[Aaron Leventhal]

Attachment: Attempt to fix more general case for any <window> -- needs help from hyatt (why does it makes entire chrome go crazy?)

Comment 32

[Aaron Leventhal]

Attachment: Oops, this is the one I need checked out - attempt at creating binding for <window> that sets initial focus - makes UI go awry

Comment 33

[David Hyatt]

Trying to bind to window causes many problems.  FOr now, you just can't do it. 
Anyway the better solution is to start converting the dialogs over to <dialog>.

Comment 34

[Aaron Leventhal]

Wizards are still a problem.

They have been spun off to bug 103348

Comment 35

[sairuh (rarely reading bugmail)]

vrfy fixed --at least for Prefs, Find and the helper app dialog.

bugs for specific dlgs should be/have been filed seperately. :)