On Thu, Jan 14, 2010 at 8:19 AM, Nico Weber <tha...@google.com> wrote:
> It probably depends if you want to use this for text input or "action"
> inputs. A text-to-speech extension would probably want to set unicode
> characters, while something that (say) hits cmd-f to open the find bar
> probably wants to use keycodes.
Text-to-speech is a different problem; this is for actions.
> For example, on OS X hitting cmd-"f" with a hiragana keyboard layout
> opens the findbar, while just pressing "f" opens an IME.
>
> If you want to use this for actons, I would find it more useful to
> have a "performUiAction()" function instead though, since keyboard
> shortcuts are different across platforms (all mac shortcuts use cmd
> instead of ctrl for example, and the letters for a few shortcuts are
> different on OS X too for various reasons).
I completely agree; I would like to add many functions along the lines
of performUiAction. However, there are a few actions for which typing
a key really is the right thing to do - for example pressing Tab to
move to the next control.
There's also testing. This function will allow you to use only
javascript to test that a particular capability can be accessed using
only the keyboard. I'm already using this for testing this API, by
simulating pressing Ctrl+L to focus the location bar and then checking
to see that the proper focus event is generated.
So the way I look at it is: there are some great uses for this
function. There are also things that this function could be used for
but there'd be a better way. It could also be abused to do things that
make no sense.
I don't think that's an argument not to allow the function; I think it
just means we should make sure it's defined properly for the intended
use, and over time try to provide better alternatives for other
possible uses.
- Dominic
> Nico
>
> On Thu, Jan 14, 2010 at 7:26 AM, Dominic Mazzoni <dmazz...@google.com> wrote:
>> Hi Darin,
>>
>> Erik suggested you might have some thoughts. In my proposed extension
>> api for accessibility (http://codereview.chromium.org/402099) one of
>> the functions is to simulate a key press. How should the client
>> express the key they would like to press? The current proposed
>> function prototype is:
>>
>> {
>> "name": "simulateKeyPress",
>> "type": "function",
>> "description": "Simulate pressing a key.",
>> "parameters": [
>> {
>> "type": "object",
>> "name": "keyInfo",
>> "properties": {
>> "key": {"type": "integer", "description": "The code of
>> the key to press, corresponding to event.keyCode."},
>> "control": {"type": "boolean", "optional": true,
>> "description": "True if the control key is down."},
>> "shift": {"type": "boolean", "optional": true,
>> "description": "True if the shift key is down."},
>> "alt": {"type": "boolean", "optional": true,
>> "description": "True if the alt key is down."}
>> }
>> }
>> ]
>> }
>>
>> What do you think? Should the key be a keyCode? A charCode?
>>
>> Should it be cross-platform, or should it match what would be returned
>> by an onKeyDown handler? Are those even mutually exclusive?
>>
>> My current thinking is: the symmetry of using the same key codes
>> returned by onKeyDown is appealing. Also, even though there are some
>> differences, the most common keys needed to automate the UI (tab,
>> enter, arrows, alphanumerics) are already consistent across platforms.
>>
>> Thanks,
>> - Dominic
>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>> http://groups.google.com/group/chromium-dev
>>
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
