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

André Bargull andre.bargull at udo.edu
Wed Feb 4 10:51:15 PST 2009



On 2/4/2009 7:35 PM, P T Withington 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?

That's the tricky part: when keyup for v is send, the ctrl modifier is 
still set! Just as documented in LPP-7678:

 >>> 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)




> 
>> (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.
>>>>>>>
> 
> 


More information about the Laszlo-dev mailing list