fourway() event gets stuck ?

[motatoes]

When I test the Getting started code (demo here), and hold CTRL + UP_ARROW + E_KEY , the character keeps moving upwards infinitely.

Notes:

• Getting started guide uses crafty v0.5.3
• I have tested on FF 24 and chrome 29.0 on a Windows machine
• Same behavior observed when i press WINDOWS_KEY + (any_arrow).
• Similar behavior observed when i press CTRL + (any arrow key) + (A or S or W or E or D or Q)
• Same behavior observed when I test with local code that uses v0.5.4

Not sure what's going on but if someone points out what might be causing the problem I'm happy to investigate and submit a patch

[potomak]

I confirm this behavior on GNU/Linux (Ubuntu 13.04) and Chrome 30.0.

Note: if I use the combination CTRL + UP_ARROW + E_KEY the player keeps moving downwards indefinitely, with DOWN_ARROW it goes upwards, I observe a similar behavior with left and right arrows.

[starwed]

Maybe this is a problem with how key events are tracked?

@moehabib , @potomak : Do either of you have a fiddle/etc that demonstrates the issue?

[motatoes]

@starwed Sorry for the delay -- This fiddle is a minimal demonstration of the issue with fourway(): http://jsfiddle.net/potatoes/Eyp6R/ (Just try a combination of the keys stated previously)

I tried to track the error by logging the value of this._movement.x at the end of this function -- It seems to me that when the issue occurs, the logged value of this._movement.x is not zero, which would explain the indefinite movement.

Still not sure what it causing this to happen though, I will try to investigate more.

[kevinsimper]

Hmm, that is weird. I can also do that in your fiddle. The fiddle is using Crafty 0.5.4 allthrough, but i can confirm this error also on 0.6 second beta.

I can stop the movement, by pressing the same keys (on osx cmd + e + down) but reverse direction (cmd + e + up). This bring the square to stop. But if i hit just the up key, it starts going infinite up, the reverse of where it was going infinite on the first error.

@moehabib as you point out, it is because the movement is never subtracted again, when the keys is lifted, like the function is never actually being run.

[starwed]

If you hold down cmd, then press the arrow, then release the arrow before the cmd key, no keyup event fires in Crafty. I don't think it actually has to do with the e key at all -- though that probably makes it more likely that you release the keys in a particular order?

Since the entity never gets the key up event, of course it keeps moving in that direction.

[starwed]

Ah, this is just a general behavior on Mac:

• On a few things you may not know about the hellish command key and javascript events
• NSResponder not receiving keyUp event when Cmd ⌘ key held down
• Why does Javascript drop keyUp events when the metaKey is pressed on Mac browsers?

I can't see a solution for detecting keyup events when the meta key is down, which is kind of crazy.

The best I can come up with is basically unpressing all keys when the meta key is held down, and then not registering key down events until it's released again? That at least prevents the keys from getting "stuck". Then, we could trigger keyup events only if the key was currently known to be down.

[starwed]

Hmm, the original issue was on Windows, which shouldn't have this particular problem. But I don't have a windows machine to test on, and I can't reproduce on a mac.

Something very similar can occur when the window loses focus (we can't track keyup events when out of focus), so maybe that's related on windows? The solution would be to do something similar to my suggestion above when we lose focus.

[ashes999]

I can reproduce this in my game with CTRL+UP+E. I'll post a link shortly (as soon as I resolve a different key-binding issue).

Link: http://deengames.com/labs/a-day-and-a-night-v0-1/

[ashes999]

Can we please get this fixed in 0.6.2? @starwed

[ashes999]

I think I figured out the root problem.

After playing around, I noticed that this only happens when you have events that change focus from the game to the browser window.

For example, in Chrome:

• CTRL+H (history) - opens a new window
• CTRL+F (find) - opens a find box
• CTRL+G (find next) - opens a find box
• CTRL+E (change address bar value) - moves cursor there

The simplest repro case is:

• Hold down the arrow key
• Press something that shifts control to the browser (eg. CTRL+E, CTRL+H)

This does not appear unique to any one browser or OS.

Instead of the key-up event firing, the event continues to trigger continuously in crafty.

Note CTRL+H is a special case; closing history makes you move twice as fast.

The solution seems quite simple: if you add an onblur function to the body element, and call keyup for all keys inside, that will solve the problem. I tested it on the cases above (added the event via HTML on the page, and checked that it fires for these cases) and it seems to work.

[ashes999]

I have a partial resolution here: https://github.com/ashes999/Crafty/commit/7076c862811f914d1bc1a7cfbc845bd367553bf9

Currently, I trigger the Blur event with this code in my index.html file:

                <script type="text/javascript">
            function craftyTriggerBlur() {
                Crafty.trigger('Blur');
            }
        </script>
    </head>
    <body onblur="craftyTriggerBlur()"> 

Edit: I changed the event from Blur to CraftyBlur, and added Crafty.addEvent(this, document.body, "onblur", Crafty.detectBlur);, but it seems that the event is not firing for these cases.

Please provide a code review and some insight @starwed

[starwed]

@ashes999 You've essentially got the right idea -- when we lose focus, treat that as the same as a keyup event for the whole keyboard.

We wouldn't want to fix this locally in "Multiway", however. It should be "at the source", in the same part of the engine that fires the "KeyUp" and "KeyDown" events.

Thanks for figuring out the specific source of the CTRL+E bug! We should also fix the CMD+anything bug on mac in a similar way.

[ashes999]

Ok, I'll see if I can fix this. What I need from you is:

1. Please read my updated comment about binding Crafty.detectBlur not working in addEvent
2. Where is the "source" of firing the events? Can you point me in the right direction?

If the root cause is the same on Mac, this will fix it there, too.

[kevinsimper]

If the root cause is the same on Mac, this will fix it there, too.

I would think it would be the same on mac as on Windows (Cmd + e does Uses selection for find)

[starwed]

I would think it would be the same on mac as on Windows (Cmd + e does Uses selection for find)

There's a related problem on Mac that makes things more complicated -- as described above, when the cmd key is down, it'll register keydown events but not keyup.

So

• When the window loses focus or cmd is down, we trigger keyup events for all keys
• We also stop registering keydown events, since we can no longer track keystate properly
• When we get focus back or command is released, we go back to the normal mode
• Someone could hold down a key while we've lost focus, and then release once it's back, so we probably don't want to fire keyup events in such a case.

The related code is in controls.js. keyboardDispatch is bound to the keyup and keydown events. We could either bind/unbind it, or have a flag that tells it whether to pass along events.

[starwed]

Fixed:

• Keys shouldn't stick due to loss of window focus

Remaining issues:

• Can get stuck due to cmd key nonsense on a mac
• ashes999 reports that Ctrl+H still messes things up on at least windows