I still believe that basing anything on keycode, although an obvious
thing to do, will leave lead to unnecessary fragility in the users of
this API. I understand that we ultimately will be generating
WebInputEvents, but the level of abstraction used by the API should be
a level higher than as proposed here.

I say this as a potential user of the API --- this would allow me to
significantly reduce the amount of code necessary for providing good
browser automation support for Chrome via WebDriver. With the current
suggested API, I'd have to wrap it with a large amount of additional
code to ensure it does what my users expect when the keyboard mapping
isn't a straight 104 key Windows US keyboard.

Please reconsider.

Simon

On Fri, Jan 15, 2010 at 7:27 AM, Darin Fisher <da...@chromium.org> wrote:
> Ultimately, I believe we'll need to generate a sequence of WebKeyboardEvent
> objects from this data.
>  (See http://trac.webkit.org/browser/trunk/WebKit/chromium/public/WebInputEvent.h)
> WebKeyboardEvent is the data that we send to WebKit corresponding to a
> keyboard event.  I think it is reasonable to base the extension API on this
> structure.
> -Darin
>
> 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

Reply via email to