Fix cheat code events bubbling up to the browser #5
Conversation
Some keys are used as browser shortcut keys. If these are part of a sequence, the browser may intercept the key events and take focus away from the page. For example, the Firefox accessibility.typeaheadfind feature pops the search box open when any letter/number key is pressed. This makes entering a cheat code impossible, since every keypress after the first goes to the search box. The solution is to call the `.stopPropagation()` and `.preventDefault()` methods on the key event object for keys you care about receiving so those events don't bubble up to the browser. This commit prevents events from propagating if they contribute to an active sequence. It might make sense to trap any keys that are part of any sequence, regardless of whether they're the "next" key in any sequence.
|
Good point. I think the best way to do this might actually be to pass the event object into all the callbacks so the user can decide how to handle it on a case-by-case basis. I'll make some changes to the API before closing the PR; thanks! |
|
Cool. Yeah, I was just disappointed when the cheat codes on the demo page weren't working for me. I run into this sometimes with HTML5 games where WASD controls pop open typeahead find and make the game unplayable. Games are an easier case since you have a small set of keys you always want to catch. HTML5 game frameworks usually have anti-bubbling code under the hood in their input handlers. |
|
Yeah that's kinda crappy. Maybe you're right that it should be the default behavior, after all. I'm not familiar with how the typeahead feature works -- I assume it only triggers if no input fields/text areas/etc are focused, correct? What sort of keys trigger it? I would probably want to only preventDefault for those keys to keep behavior as "transparent" as possible (for instance, the arrow keys and pgup/pgdn should still scroll the page). |
|
In the Firefox case, yeah, typeahead find only triggers when no input/textarea is focused and you press a key that generates a character. So letters, numbers, and punctuation all initiate find-in-page, but F-keys, navigation keys, and modifiers don't. You can test it by turning on It may not make sense to catch everything. Like, if no registered sequence uses the letter 'f', there's probably not much sense in catching it. And if cheet.js is the first to answer a key event but there's a game or app running on the page that wants key events, too, you may need a way of turning propagation back on. Then again, if there's a game/app on the page, maybe cheet.js isn't the right solution anyway. 🐸 |
Some keys are used as browser shortcut keys. If these are part of a
sequence, the browser may intercept the key events and take focus away
from the page.
For example, the Firefox
accessibility.typeaheadfindfeature pops thesearch box open when any letter/number key is pressed. This makes
entering a cheat code impossible, since every keypress after the first
goes to the search box.
The solution is to call the
.stopPropagation()and.preventDefault()methods on the key event object for keys you careabout receiving so those events don't bubble up to the browser. This
commit prevents events from propagating if they contribute to an active
sequence. It might make sense to trap any keys that are part of any
sequence, regardless of whether they're the "next" key in any sequence.