- From: Jason Juang <juangj@google.com>
- Date: Wed, 18 May 2016 11:41:19 -0700
- To: James Graham <james@hoppipolla.co.uk>
- Cc: "public-browser-tools-testing@w3.org" <public-browser-tools-testing@w3.org>
- Message-ID: <CAN_hBkx3MiwdCDvGOOjQ3vm+5FCOSahS5zvnPaAuZXCekwDp9g@mail.gmail.com>
For #3, in the case where the modifier key is already pressed: [ {type: keyDown, value: shift}, {type: keyDown, value: "A"} ] you would probably not generate additional events for the shift key, and the modifier would continue to be set for subsequent keys until shift is released. However, what about the opposite case? [ {type: keyDown, value: shift}, {type: keyDown, value: "5"} ] Should the shift key be implicitly released before the "5" and re-pressed after? Does this generate a keyPress for "%"? On Wed, May 18, 2016 at 7:32 AM, James Graham <james@hoppipolla.co.uk> wrote: > I am assuming, for now, that key actions will act as if there was a 102 > key US English keyboard for the purposes of translating a character to a > key. However this leaves an open question about what to do in the case > where a modifier is used to achieve a given character. For example if I send > > { > "type": "keyDown", > "value": "A" > } > > what should happen about the shift key? I think there are four options: > > 1) You get no key* events for shift, but the modifier bit is set. The > modifier is not set for subsequent key actions. I think this is unphysical? > > 2) As 1) but the modifier remains set for subsequent key actions until it > is explicitly unset. > > 3) An explicit keyDown/keyPress event pair is generated for the shift key, > then the events related to the "a" key are generated, then an explicit > keyUp for the shift key. > > 4) As 3) but without the keyUp, so that subsequent key actions have the > shift modifier set. > > I think I favour 3, but there are probably all kinds of subtleties here. > >
Received on Wednesday, 18 May 2016 18:42:13 UTC