[Laszlo-dev] UPDATED For Review: Change 20090203-hqm-r, Summary: Fix for missing key up events in swf runtime

[André Bargull]

The KeyboardEvent#ctrlKey modifier maps to both, the command key and the 
ctrl key, from AS3 docs:
---
On Windows and Linux, indicates whether the Ctrl key is active (true) or 
inactive (false); On Mac OS, indicates whether either the Ctrl key or 
the Command key is active.
---

On 2/4/2009 8:00 PM, Chris Helgeson wrote:
> Don't know if it is relevant but on Mac it is not the ctrl key it is the 
> command key (different keycode). Are we looking for the right sequence?
> 
> - Chris
> 
> On Feb 4, 2009, at 10:35 AM, P T Withington <ptw at pobox.com> wrote:
> 
>> On 2009-02-04, at 12:52EST, André Bargull wrote:
>>
>>> As it works in DHTML+IE, your workaround should be integrated into 
>>> the swf8/9-kernel and not in the general LzKeys service. And there 
>>> also needs to be a different logic for each platform (IE and OSX).
>>> Because in IE there are (at least) two different problems:
>>> (1) the keyup-event for 'v' in a ctrl-v sequence is generated, only 
>>> the keyup-event for ctrl is missing
>>
>> Can't we infer that if we see up for v with no ctrl modifier that ctrl 
>> has been released?
>>
>>> (2) or no events for 'v' are generated at all
>>
>> I agree that if we get no events at all, it will be hard to work 
>> around.  :)
>>
>>> At least this is my experience for SWF9+IE, which is documented in 
>>> LPP-7678. And in addition to those bugs, there's no 3:
>>> (3) press ctrl, hold down, press a-key (down and up), press again 
>>> a-key (down and up), result: same as for (1) (expected events: down 
>>> ctrl, down a, up a, down a, up a, up ctrl)
>>>
>>>> Press ctrl-key, hold down and press then a-key:
>>>> - if you release first the a-key and then ctrl, you'll get:
>>>>> down for 17 (alt=false, ctrl=true, shift=false)
>>>>> up for 65 (alt=false, ctrl=true, shift=false)
>>>
>>>> - but if release first ctrl and then the a-key:
>>>>> down for 17 (alt=false, ctrl=true, shift=false)
>>>>> up for 17 (alt=false, ctrl=false, shift=false)
>>>
>>>
>>> IMO, problem (2)+(3) are not fixable.
>>> For problem (1), it's unclear when to send the keyup-event for ctrl:
>>> - at the same time when keyup for 'v' is send? That could be too 
>>> early, maybe ctrl is still down at that time (e.g. compare to (3))
>>> - when the next key-event is triggered (then depending on the 
>>> KeyBoardEvent#ctrlKey flag), but that could be too late
>>>
>>>
>>>
>>> On 2/4/2009 2:28 AM, Henry Minsky wrote:
>>>> Hmm, well maybe we should put in a workaround conditionalized for the
>>>> IE7 / Win or OSX. It is annoying
>>>> when you cut and paste in the app and then the Enter command doesn't
>>>> work in the debugger anymore. The workaround is not great, because it
>>>> may guess wrong that the command key has been released, but it
>>>> is really annoying when the LFC thinks it is stuck down, so I favor
>>>> doing this workaround until the Adobe bug
>>>> is fixed...
>>>> On Tue, Feb 3, 2009 at 8:06 PM, André Bargull 
>>>> <andre.bargull at udo.edu> wrote:
>>>>> That's exactly the same problem which was described in [1]. It 
>>>>> works as
>>>>> expected with WinXP + Firefox/Safari/Opera, it's just the ActiveX 
>>>>> Player
>>>>> which is broken.
>>>>> Max and Tucker found a couple of related flash player bugs [2]. So 
>>>>> it's a
>>>>> known Adobe issue and therefore LPP-7678 was resolved as "Not Laszlo".
>>>>>
>>>>> [1] http://www.openlaszlo.org/jira/browse/LPP-7678
>>>>> [2] FP-1237, FP-815, FP-891 and FP-106
>>>>> (http://bugs.adobe.com/jira/browse/FP-NNNN)
>>>>>
>>>>> On 2/4/2009 1:41 AM, Henry Minsky wrote:
>>>>>> I'm using IE7 on Windows XP, running under Parallels on OSX.
>>>>>>
>>>>>> Here is a trace in swf9 of the key events that are received by the
>>>>>> kernel listener, for two cases
>>>>>> of typing "ctrl-c". The first case the control key is pressed and
>>>>>> held, then the 'c' key is  pressed then released, and then the 
>>>>>> control
>>>>>> key is released.
>>>>>>
>>>>>> ctrl-down c-down c-up ctrl-up
>>>>>>
>>>>>> __keyboardEvent 17 onkeydown ctrlKey: true
>>>>>> __keyboardEvent 67 onkeyup ctrlKey: true
>>>>>>
>>>>>> Note there is no 'c' key down event, but there is a key up event for
>>>>>> it. The the value of KeyboardEvent.ctrlKey is true because the ctrl
>>>>>> key is still down.
>>>>>>
>>>>>>
>>>>>> I tried another sequence, which might be something that someone types
>>>>>> by accident
>>>>>> ctrl-down c-down ctrl-up cup
>>>>>>
>>>>>> __keyboardEvent 17 onkeydown ctrlKey: true
>>>>>> __keyboardEvent 17 onkeyup ctrlKey: false
>>>>>>
>>>>>> In this case there is no "c" key up or down event, but there is a
>>>>>> control key up event.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Feb 3, 2009 at 5:49 PM, André Bargull <andre.bargull at udo.edu>
>>>>>> wrote:
>>>>>>> What is the state of KeyboardEvent.ctrlKey in that case and which 
>>>>>>> browser
>>>>>>> did you use? Because we know that the IE ActiveX Player has got 
>>>>>>> issues
>>>>>>> related to browser short-cuts (LPP-7678 - "<command /> is not 
>>>>>>> working on
>>>>>>> IE.").
>>>>>>>
>>>>>>> On 2/3/2009 11:26 PM, Henry Minsky wrote:
>>>>>>>> Hmm, in windows I sometimes see kind of the 'reverse' problem, 
>>>>>>>> where
>>>>>>>> if you type 'ctrl-v',  there
>>>>>>>> is a key-up event for the 'v', but one never comes for the 'ctrl'
>>>>>>>> key-up.
>>>>>>>>
>>
>>
>