Jesse Ruderman Reporter
	Description • 24 years ago

I should be able to press 'y' or 'n' at the "save password?" prompt, and I 
should be able to press 's' or 'd' at the "save/don't save/cancel" prompt.  Alt-
letter should work too, and the letter should be underlined in the button text.

Afaict, none of Mozilla's dialogs currently have access keys for buttons.

Depending on the implementation, bug 959 might need to be fixed first.

	Aaron Leventhal
	Comment 1 • 24 years ago

Yes, I agree with this wholeheartedly.
One should be able to press Y or Alt-Y, N or Alt-N (at least under Win/Lin).

	Matthew T (active 1999-2002)
	Comment 2 • 24 years ago

This applies to most buttons, but not to most of the examples Jesse gave. 
Mnemonics should not be provided for those buttons which are activated either by 
Enter (e.g. `Yes' or `Save') or by Escape or Command+. (e.g. `No' or `Cancel').

Reference:
<http://msdn.microsoft.com/library/books/winguide/ch05c.htm>
<http://developer.apple.com/techpubs/mac/HIGOS8Guide/thig-10.html>

Because Mac OS convention is to use the Command key to activate access keys where 
they are provided for controls, and Command is also used for keyboard shortcuts 
(such as Command+V for Paste), use of the following accesskeys should be avoided 
if there is an equally obvious alternative: A, C, Q, V, W, X, Y, Z. If we decide 
to break with convention, and use Control to activate accesskeys on Mac OS, then 
this won't be a problem. I'll comment in bug 959 about that.

	timeless
	Comment 3 • 24 years ago

On windows in most cases you don't need to press alt, simply pressing the key 
results in the action, the exception is of course for editboxes.

ACVXZ are ok for dialogs that don't have edit boxes.  On windows [and macos], 
dialogs don't accept ctrl-w [cmd] as a close mechanism, so it is also 
available.

	Jesse Ruderman Reporter
	Comment 4 • 24 years ago

Most Windows apps with Yes/No dialogs use 'y' and 'n' as access keys, and the 
msdn article only mentions OK and Cancel.  The only exception I've found so far 
is AIM's dialog when you get an IM from someone not on your list, and it does 
accept Alt-y and Alt-n.

	timeless
	Comment 5 • 24 years ago

refer to the MSDN article's Appendix B, "Keyboard Interface Summary." 
http://msdn.microsoft.com/library/books/winguide/appxB.htm

&Save &Open &Yes &No. among a long list.

	Alec Flett
	Comment 6 • 24 years ago

file another bug against the mailnews dialogs. This one will just be for yes/no
dialogs that we find in the app.

	sairuh (rarely reading bugmail)
	Comment 7 • 24 years ago

okay, filed bug 65659 for mailnews dialogs.

	Jesse Ruderman Reporter
	Comment 8 • 24 years ago

I just marked bug 72771 ("Confirmation yes/no dialogs don't allow keyboard 
input") as a duplicate of this bug, but bugzilla forgot to say something on 
this bug.

	Aaron Leventhal
	Comment 9 • 23 years ago

alecf should never have had this one.
Jag, can you take this?

	jag (Peter Annema)
	Comment 10 • 23 years ago

hewitt, does your new dialog binding tackle this?

	Joe Hewitt (gone)
	Comment 11 • 23 years ago

I'll take this one

	Olav Vitters
	Comment 12 • 23 years ago

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

	Peter Trudelle
	Comment 13 • 23 years ago

nsbeta1- per ADT triage team, ->1.2

	Dean Tessman
	Comment 14 • 23 years ago

re: comment 2, the standard on Windows is to underline the access keys on
MessageBoxes, except for OK/Cancel.  &Yes, &No, etc. should all have the access
key underlined.

Note: There's another bug somewhere on not displaying the access keys depending
on the Windows pref.

	Joonas
	Comment 15 • 23 years ago

The bug Dean mentions is bug 25894. I'm a voter on that one.

	Matthew T (active 1999-2002)
	Comment 16 • 23 years ago

> This one will just be for yes/no dialogs that we find in the app.

In that case, this bug is invalid. Yes/No alerts that we find in the app 
shouldn't have salt rubbed into them by adding access keys to the buttons; they 
should be fixed so that they don't use Yes and No.

	R.K.Aa.
	Comment 17 • 22 years ago

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

	Jesse Ruderman Reporter
	Comment 18 • 22 years ago

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

	Aaron Leventhal
	Comment 19 • 22 years ago

-> Akkana

	sairuh (rarely reading bugmail)
	Comment 20 • 22 years ago

akkana, would you have time for this for buffy? (or, at least any of its blockers?)

	Dean Tessman
	Comment 21 • 22 years ago

I think that Yes, No, Save, Don't Save, and Revert can be handled centrally in
nsPromptService::ConfirmCheckEx, and maybe also touching Confirm and ConfirmCheck.

	Akkana Peck Assignee
	Comment 22 • 22 years ago

This bug probably shouldn't be on my plate; at this point, it sounds like it's
waiting for either (a) a policy decision on what, if any, access keys generic
prompt dialogs should have, or (b) fixes to a few specific dialogs' chrome.  If
it's b, the bug should be assigned to whoever owns the specific dialog(s).  

In the case of (a), in case any non-Unix people care about my opinion, I
recently had this same problem arise in a little C program I distribute, and my
solution there was to make an API for a generic blocking prompt like this:
int PromptDialog(char* question, 
                 char* yesStr, char* noStr,      // displayed on the btns
                 char* yesChars, char* noChars); // chars to activate btns
I agree with Matthew that dialogs buttons should describe specific actions
(Delete, Quit, Save) rather than Yes/No, and consequently the accel characters
should change based on what the strings on the buttons say.  It doesn't look
like this quite fits any of the current nsIPromptService dialogs -- none of them
seem to allow setting both the yes and the no strings, let alone passing in
accel characters to activate each button (in my API they are char* because often
there are multiple characters that should activate the same button, for example,
q, Q, return, and space).

Adding cmanske: Charley, have you done any work solving this for editor dialogs?
 Who owns nsIPromptService, and how did they expect accelerators to be handled?

	Charles Manske
	Comment 23 • 22 years ago

I'm glad to see this issue has finally been addressed!
The "Yes/No" common dialogs obviously have default strings, e.g.: 
"Yes", "No" / "Esc", "Cancel", whose's access keys should be defined in the 
same stringbundles as those strings. But many users of nsIPromptService,
such as Composer, do supply their own strings for button text. It only seems 
logical that the accesskeys should be supplied by those users and defined in the
same DTD or stringbundle files as the button text. IMHO, we should add accesskeys
as additional parameters to the nsIPromptService interfaces.
If not supplied, I would suggest that the first letter of each supplied button
label is used for the accesskey.

	Aaron Leventhal
	Comment 24 • 22 years ago

If these Yes No dialogs are all using nsIPromptService, then this should be a
dup of bug 134066.  nsIPromptService is owned by ccarlen.

nsIPromptService has a set of default names for buttons, like Yes, No, Okay,
Cancel. There should be a set of corresponding accesskeys for those, as well as
a way to supply your own accesskey.

I spoke with ccarlen and hewitt about creating something a token something like
&_; in XUL, meaning make the next character the accesskey. This would make it
easier to pass strings around with accesskeys, instead of adding more arguments
to methods in nsIPromptService which already have a lot of arguments. However,
ccarlen wan't opposed to extra arguments either.

	Akkana Peck Assignee
	Comment 25 • 22 years ago

Looks like this indeed should be a dup.

*** This bug has been marked as a duplicate of 134066 ***

	Jesse Ruderman Reporter
	Comment 26 • 22 years ago

"Want to know why I won't use Mozilla on Windows? When a yes/no dialog pops up,
I can't type 'Y' or 'N' to dismiss it. Stupid things like this, problems that
were solved 15 years ago, still plague us."

http://apple.slashdot.org/comments.pl?sid=39488&cid=4215992

	sairuh (rarely reading bugmail)
	Comment 27 • 22 years ago

mass-verification of Duplicates.

mail search string for bugspam: SolarFlaresAreTheCause