Closed
Bug 64457
Opened 24 years ago
Closed 22 years ago
Yes/No buttons in dialogs need access keys
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P2)
Core
DOM: UI Events & Focus Handling
Tracking
()
VERIFIED
DUPLICATE
of bug 134066
mozilla1.2alpha
People
(Reporter: jruderman, Assigned: akkzilla)
References
(Blocks 1 open bug)
Details
(Keywords: access, meta)
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.
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).
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.
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.
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.
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.
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.
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla1.0
Reporter | ||
Updated•24 years ago
|
Summary: Dialog buttons need access keys → Yes/No buttons in dialogs need access keys
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.
Updated•24 years ago
|
Comment 9•24 years ago
|
||
alecf should never have had this one.
Jag, can you take this?
Comment 10•23 years ago
|
||
hewitt, does your new dialog binding tackle this?
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla0.9.9
Comment 12•23 years ago
|
||
*** Bug 117360 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Target Milestone: mozilla0.9.9 → mozilla1.0
Comment 13•23 years ago
|
||
nsbeta1- per ADT triage team, ->1.2
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.
Comment 15•23 years ago
|
||
The bug Dean mentions is bug 25894. I'm a voter on that one.
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.
Comment 17•23 years ago
|
||
*** Bug 148686 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 18•23 years ago
|
||
*** Bug 150883 has been marked as a duplicate of this bug. ***
Comment 20•23 years ago
|
||
akkana, would you have time for this for buffy? (or, at least any of its blockers?)
Comment 21•23 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.
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?
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.
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.
Assignee | ||
Comment 25•22 years ago
|
||
Looks like this indeed should be a dup.
*** This bug has been marked as a duplicate of 134066 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Updated•22 years ago
|
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
Comment 27•22 years ago
|
||
mass-verification of Duplicates.
mail search string for bugspam: SolarFlaresAreTheCause
Status: RESOLVED → VERIFIED
Updated•6 years ago
|
Component: Keyboard: Navigation → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•