Closed BorisKozo closed 11 years ago
could this have a potential downside if a gamer is switching tabs back and forth.. will this patch need him to click the canvas before he can start to control his player again?
No, this is completely unrelated. What happens now is that you register on the mouseup and mousedown events of the entire window so if I have something like this in my code:
jaws.on_keydown("left_mouse_button", function () {
Then the browser will route all mouse events to that function so comboboxes, scrollbars and other elements unrelated to the game will now route to that function too. The problem continues because in the handler code there is this line:
on_keyup_callbacks[human_name](human_name)
e.preventDefault()
Which means all UI elements in the window that rely on the mouse stop functioning. I think the desired behavior is to override this event for the canvas only and this is what my patch does.
That said, I realized that on_keydown("left_mouse_button")
is not useful because of two reasons:
e.preventDefault()
) I cannot use it in more than one place. In my case I wanted to use it within a button sprite but only the first instance of the sprite can handle the event.I am going to change my code to using jaws.pressed("left_mouse_button")
anyway but I thought I fix that issue before.
You can check out the game I am developing at: http://boriskozo.github.com/Explosio/ where the clicks that create the explosions are still using jaws.on_keydown("left_mouse_button")
Currently the mouse events have handled = true on them and therefore the page (entire window) becomes unresponsive to mouse clicks if you register on the mouseup/mousedown events. I moved the event registration to the canvas only.
I will make a similar fix to touchup and touchdown once I figure out why they don't work on Safari.