Defining terms in "handling keyboard events" better

[garykac]

From @domenic on November 22, 2016 18:35

The isFullscreen check should check if a specific document's fullscreen element is non-null, instead of the current vague phrasing + implementation suggestion.

I'm not sure what "input focus" is, but if it's the same thing as normal focus, then it should check if a specific document's fullscreen element is the currently focused area of a top-level browsing context

In general this algorithm should probably either get moved into or replace https://html.spec.whatwg.org/#fire-a-focus-event. It seems like they are both trying to do the same thing. The HTML version has some more precise wording, but is of course missing the fullscreen and system keyboard lock stuff. I'd suggest copying as much from HTML as looks correct then adding your system keyboard lock stuff as you've done, with the tweaks above. We can eventually either move it back into HTML or have HTML link to this.

Copied from original issue: garykac/system-keyboard-lock#3

[garykac]

From @domenic on November 22, 2016 18:41

I guess one big difference is that this algorithm only runs "if a low-level keyboard handler is registered". I think ideally we would only have one algorithm, which runs in all cases but uses an if statement for that purpose. That way we don't have to duplicate some of the complicated stuff that HTML has.

Doing that might allow you to entirely get rid of the idea of "low-level keyboard handler" in favor of just checking enableKeyboardLock and doing some slightly different processing. Maybe the thing to do is to bail out if the key is a system keyboard combination, unless all the appropriate conditions are true.