Closed Bug 134066 Opened 21 years ago Closed 20 years ago

nsIPromptService does not support accesskey

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: aaronlev, Assigned: aaronlev)

References

(Blocks 2 open bugs)

Details

(Keywords: access, dev-doc-complete)

Attachments

(1 file)

When using nsIPromptService::ConfirmEx() for example, there is no way to ask for
buttons that have underlined letters (accesskey's). Thus there is no way to
associate Alt+S with _S_ave, for example.
I'm pretty sure that the cookie accept dialog uses nsIPromptService as well, so
marking this as blocking bug 107560
Blocks: 107560
-> ccarlen
Assignee: aaronl → ccarlen
Keywords: access
Suppose XUL accesskeys could be coded using an entity from a DTD, like &_; right
before the letter to be underlined..
For example:
Save &_;As

To make it legal, there would have to be a DTD entry:
<!ENTITY _ "">

Then, wherever it is that we decode entities, we would SetAttribute(accesskey,
letter) when we saw thsi entity, in order to implement it.

This would make some things easier, make it possible to remove some code, and
allow nsIPromptService to support accesskey without adding additional arguments.

Is this a good idea?
why not make it much simpler and use, say, only an underscore like:
Save _As
Because presumeably _ is a legal character, that someone might want in their text.
Just spoke with danm about it. 

nsIPromptService isn't frozen. Perhaps we can do something to it without messing
up to many people.

If we choose & (as Windows does), then we'll probably need to make \& work if
they really do want an &.

Dan, would this affect a lot of embeddors?
*** Bug 64457 has been marked as a duplicate of this bug. ***
Blocks: 61877, 158421
*** Bug 61877 has been marked as a duplicate of this bug. ***
Is this work scheduled? Can we get a milestone on this?
Blocks: 144475
I told ccarlen I would do it. I know, this is important work -- until another
engineer can help out on accessibility/keyboard issues, I can't say when it will
get done. Or, ccarlen, maybe you have time for it?
Keywords: nsbeta1
Also fixes bug 133582, so that simple dialogs with "Don't ask me again"
checkboxes don't start with initial focus on checkbox, but on first button
instead.

Seeking r=
Comment on attachment 101196 [details] [diff] [review]
Allows users of nsIPromptService to insert "&" before a char to make it the accesskey (&& escapes if you really want &)

r=sgehani
Attachment #101196 - Flags: review+
Comment on attachment 101196 [details] [diff] [review]
Allows users of nsIPromptService to insert "&" before a char to make it the accesskey (&& escapes if you really want &)

sr=hewitt
Attachment #101196 - Flags: superreview+
taking
Assignee: ccarlen → aaronl
checked in
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment on attachment 101196 [details] [diff] [review]
Allows users of nsIPromptService to insert "&" before a char to make it the accesskey (&& escapes if you really want &)

>+  var accessKeyIndex;
>+  if (aLabel.charAt(0) == '&') {
>+   accessKeyIndex = 0;
>+  }
>+  else {
>+    accessKeyIndex = aLabel.search(/[^\&]\&[^\&]/) + 1;
>+    if (accessKeyIndex == 0) {
>+      accessKeyIndex = -1; // magic value for no accesskey
>+    }
>+  }
Edge case: "&&" becomes "&" with accesskey="&"?
Neil, if you mean that if the string starts with &&, you're right -- I see now
that it would make an accesskey of &.

However, if && is in the middle it works to create a real &
rs vrfy.
Status: RESOLVED → VERIFIED
*** Bug 186443 has been marked as a duplicate of this bug. ***
Keywords: dev-doc-needed
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.