wicg / keyboard-lock Goto Github PK

From @Hzj-jie on April 18, 2017 21:22

[SecureContext] void requestSystemKeyboardLock(optional sequence<DOMString> keyCodes);

should be

[SecureContext] void requestSystemKeyboardLock(optional sequence<DOMString> keyCodes = []);

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

From @Hzj-jie on April 17, 2017 18:36

This should cover the #18, as well as the implementation specific limitations. A must-have is a field to indicate whether the error could recover after a retry, or the request is rejected by user agents because of a permission request.

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

From @Hzj-jie on April 17, 2017 18:31

If we would prefer to return Promise from requestSystemKeyboardLock() function, once a web page requests twice in parallel, the second one should be rejected immediately. E.g.

function f() {
  const p1 = navigator.requestSystemKeyboardLock(['a', 'b']);
  const p2 = navigator.requestSystemKeyboardLock(['c', 'd']);

  p2.then(() => {
    assert_not_reachable();
  }).catch((e) => {
    // e should be a predefined DOMException.
  });
}

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

From @Hzj-jie on March 19, 2017 23:29

Considering the API is for all keys instead of OS reserved key combinations, I would suggest to change,
Navigator.requestSystemKeyboardLock()
into
Navigator.requestKeyLock()

And similar as
Navigator.cancelSystemKeyboardLock().

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

I can't wrap my head around whether this is meant to be a keyCode as in in the UIEvent spec but those are unsigned int or a key which are also DOMString but do not seem to represent modifiers.

A guess this issue is too fold:

• Is it keyCode or key? (or something else?)
• How to register "Ctrl+C"? Maybe this could be clarified with an example or two in the specification.

This specification has been proposed for migration to the WebApps WG (which is expected to partly replace the WebPlat WG). For this to happen, we need expressions of interest/intent to commit from at least two implementors.

Please let us know if you plan to implement this specification, or if you can point to any publicly documented expressions of interest from implementors.

The draft WebApps charter will go to the Advisory Committee (AC) within the next two or three weeks, so quick responses may make the difference.

@chaals @marcoscaceres

Same as #25 but for cancelKeyboardLock

From @mgiuca on March 23, 2017 2:0

The spec currently proposes that requestSystemKeyboardLock always succeed (in fact it does not define any possibility of failure; see #7). If not in full-screen, it is supposed to succeed but do nothing until fullscreen is entered.

Rather, it should reject if called when not in full-screen. When the enable keyboard lock flag is set, keyboard lock should work (and there should be no clause in "Handling Keyboard Events" that checks if full-screen).

Similarly, enable keyboard lock should be cleared when exiting full-screen.

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

From @mgiuca on March 23, 2017 2:2

There should be an event fired when keyboard lock is exited. It should be possible for the User Agent to decide to kick the user out of keyboard lock at any time, and the page should be notified.

See #9 (should kick out when exiting full-screen).

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

From @Hzj-jie on March 31, 2017 21:6

@dtapuska mentioned this good question.
Once a web page requests some keys, according to #9, these keys should not be processed by browser. The behavior may introduce the out of order key events. E.g.

• Web page requests "W" key.
• User types "Q" and "W" in sequence.
• "Q" is consumed or delayed by browser processing logic, maybe IME.
• Web page receives "W" then "Q", or "W" only.

I do not think this could be a big deal. If the web page needs both "Q" and "W", it should request both keys. Otherwise, relying on "Q" is not a reasonable behavior. But we may explicitly call out this issue in the spec.

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

I may be understanding the spec incorrectly, but from the steps described it seems like sending in a set of invalid keys would result in capturing all keys.

Would it make sense to reject the promise?

In section 2, there is a "valid KeyboardEvent code" that links to another document but the anchor seems to no longer exist.

Per spec ctrl+v shouldn't work on element, but looks like at least Chrome doesn't prevent that if lock(["KeyV"]) is used.

Just checking in if this incubation is still active or if we should consider archiving?

Handling Keyboard Events has a special case for this. I'm wondering if there are cases where it's possible for a document to receive key events without being in focus.

From @foolip on April 18, 2017 4:41

Given that implementation is starting in https://codereview.chromium.org/2805763004 and the rough shape of the spec is done, this would be a good time to request TAG review at https://github.com/w3ctag/spec-reviews/issues

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

The reason is primarily for UX - so that the message to the user (about how to exit) is displayed when they enter fullscreen.

From @domenic on November 22, 2016 18:25

This term should probably be defined somewhere separate from the algorithm that registers it. Then it can get the proper treatment it deserves in terms of what normative effects it has, the interesting notes nearby, and so on.

It should explain what normative effect it has in as much detail as possible, although understandably this is kind of difficult. Currently it says "process keyboard events". Maybe expand on this a bit, i.e. something like "ensure that KeyboardEvent events are fired instead of performing the usual action of the system keyboard shortcut".

Also, it would be best to not use "event handler" since that has a specific meaning. Maybe "keyboard trap" or similar would be better.

Also, consistently use low-level or low level. I think with a hyphen is a bit better?

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

In the sum of all IDL, there are two definitions of the Keyboard interface:
https://wicg.github.io/keyboard-lock/#keyboard-interface
https://wicg.github.io/keyboard-map/#keyboard-interface

This is a problem if trying to parse all IDL together to figure out the sum of all API surface, as I'm attempting now.

Making one of these a partial interface would fix the problem.

Twin issue: WICG/keyboard-map#25

From @foolip on April 17, 2017 8:8

They're linked from the top of https://garykac.github.io/system-keyboard-lock/

Relatedly, please pick a single "shortname" and use it everywhere. In https://codereview.chromium.org/2805763004 tests are being added under keyboard-lock/ in web-platform-tests. Bikeshed: I prefer that to the longer system-keyboard-lock.

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

I'm very uncomfortable with this API locking the [esc] key.

I can see that Special Considerations with the Escape Key have been made (ref issue 45), where:

...the user agent shows a user message "Press ESC to exit fullscreen" when
Javascript-initiated fullscreen is activated, then that message will need to
be updated when keyboard lock is in effect to read "Press and hold ESC 
to exit fullscreen".

I highly doubt users will read/notice a standard message that will typically disappear within a few seconds... but there is still a chance that users will press the [esc] key to escape from whatever full-screen thing they have fallen in to (I doubt many will continue to hold for 2 seconds).

Personally I want the Escape key to be excluded from this feature... I believe it should always Escape the view the user is currently in.

From @dtapuska on March 29, 2017 13:42

https://garykac.github.io/system-keyboard-lock/#enable-keyboard-lock is a little confusing. Are you defining a property on the Navigator IDL? If so why isn't it there? Is it read only, what are the semantics of it?

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

The example in this section shows the promise returned by lock( ) as pending until the System key press handler is created and activated.

As I've been implementing this feature I've found one problem with this assumption which is that we don't expect the javascript caller to request keyboard lock more than once because the user agent will apply/remove the lock as appropriate, however there isn't a way to indicate when keyboard lock is active/inactive after the first lock event. An example where this doesn't work is where the UI loses and receives focus while in fullscreen. In that case the hook will be removed and recreated (some OSes like Linux do not allow for a hook to 'pass-through' key events, you receive the keys you request and cannot pass them down the handler chain) but the user agent cannot communicate these states to javascript.

I think the promise should resolve if the user agent is able to register the request (i.e. the method was called correctly and the request has been registered such that the hook will be activated when the UI is in the appropriate state).

#34 is once case this could happen - another case would be in a platform/configuration/user preference where either it is undesirable to do so (as noted in the mobile platform bit on the spec) or the user rejects the lock. (either by an ephemeral preference or as a persistent preference, given that the implementation provides such a feature)

From @Hzj-jie on April 18, 2017 21:28

If the web page has not actively called cancelSystemKeyboardLock(), whenever the unloading document cleanup steps run with a document, cancelSystemKeyboardLock() is implicitly called. i.e. The keyboard lock API is session-based, and won't be kept by the user agents.

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

Applications like ours bring full video games into the web browser. As such certain games require users to lock the mouse to the page to pass relative mouse movement (FPS games are the primary example).

Pressing ESC will cause Pointer Lock to end and then the user needs to retype the keystroke to relock the mouse. I haven't seen any discussion on this in the spec so I figured I'd bring up the use case. Ensuring the user can press ESC and pass the input to the game while in fullscreen while preserving the pointer lock is important.

"Copy the values from keyCodes into reserved key codes, removing any entries which are not valid KeyboardEvent codes or duplicate." is a bit too vague. Maybe it would be worth having a clear algorithm such as:

- Let keyList be a set of keyCode.
- For each value of keyCodes, if it is a valid KeyboardEvent code and is not already in keyList, insert it into keyList.
- Copy keyList into reserved key codes.

The example here shows javascript requesting 'KeyW' and all W key combinations being sent to the website, however this is only true on qwerty keyboards. The example does call out that it is using codes but it is probably worth some clarification on what would happen for azerty keyboards here (and what to do about it).

Reading the spec, it seems that it does nothing. For compatibility, I would recommend being explicit about it. In general, it's better to phrase things like:

[...]
- If enable keyboard lock is true, abort these steps.
- Register a system key press handler.
- Set enable keyboard lock to true.

From @dtapuska on March 29, 2017 14:4

When reading:
https://garykac.github.io/system-keyboard-lock/#key-press-handler

It seems that the "system key press handler" is describing an implementation. An alternate implementation is that you could just have a table and know that the registered document/navigator has priority over executing the UA default action for these events.

It isn't clear to me that you need to hook the system listeners in order to implement this.

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

From @Hzj-jie on March 19, 2017 23:40

Considering this is an extremely powerful API, which allows webpage to intercept any keys. Some browser vendors may implement a user notification or prompt to decide whether these APIs should be allowed or now. Meanwhile, web page may need a signal to indicate when the reserved keys are available, or whether the user declined the request. So it may fall back to use alternative keys.
So I suggest to change
void Navigator.requestSystemKeyboardLock()
into
Promise<void> Navigator.requestSystemKeyboardLock()

Once the Promise resolves, the web page should be able to retrieve the keys it requested.
The Promise will reject only if the user actively disallowed the API.
Due to the "best effort" principle of these APIs, no matter whether the keys or key combinations can be successfully retrieved, e.g. ctrl+alt+del is never cancelable on Windows, the Promise always resolves, once users or browser allowed the API.

void Navigator.cancelSystemKeyboardLock()
is not impacted by this change.

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

From @domenic on November 22, 2016 18:22

One big issue to figure it is where the enableKeyboardLock and reservedKeyCodes are meant to be stored. They're certainly not stored in "the user agent", as that would mean that they are the same across all web sites. I see a few choices:

• The browsing context (~ a "tab" in your browser). This seems unlikely, as it would mean they persist across navigation within that browsing context (even to cross-origin sites).
• Every Window/environment settings object (they are 1:1). This would mean that if you inject code into about:blank and then navigate, the keyboard lock would be preserved (the Window is reused so all its values remain). But if you do document.open(), the keyboard lock would be lost (the Window is re-created).
• Every Document that has a browsing context. (The latter clause is important so that document.implement.createDocument() or XHR responseDocument do not get this ability.) This would mean that navigating from about:blank to a new document loses keyboard lock, but doing document.open() does not.

So probably either Window or Document. I don't see a real reason to prefer one over the other; maybe Document is most conventional.

Once you've figured that out, it's important to say how to get to that variable inside your algorithms. So, let's say it was Window. Then step 1 of requestSystemKeyboardLock would be:

1. Reset this Navigator object's relevant global object's reservedKeyCodes to be an empty sequence.

If it was the Document, it would be

1. Reset this Navigator object's relevant global object's associated Document's reservedKeyCodes to be an empty sequence.

Similarly for references to enableKeyboardLock and so on.

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

From @Hzj-jie on April 2, 2017 23:5

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

TAG review recommended renaming the API to be consistent with other similar APIs.

Change:
requestKeyboardLock -> keyboardLock
cancelKeyboardLock -> keyboardUnlock

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

From @domenic on November 22, 2016 18:37

• Missing closing parens in "(which would capture all keys if enableKeyboardLock was enabled."
• Is reservedKeyCodes a sequence or list? Either seems fine, but pick one and stick with it.

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

Because there are other proposed APIs that would make use of a keyboard object, it makes sense to move these methods there instead of dumping them directly in navigator.

This was one of the ways proposed in the TAG review

navigator.keyboard.lock()
navigator.keyboard.unlock()

Let say that a website author tries to register "Ctrl+Alt+Del", not knowing that this can't be registered on Windows. The current API would never let the website. Would it make sense to request requestKeyboardLock() if one or more of the keyCodes can't be handled by the UA?

From @domenic on November 22, 2016 18:37

Right now it links to an IDL member, but ideally there should be a definition like "a KeyboardEvent code is one of the following strings" in some spec.

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

Browser initiated fullscreen is a UI fullscreen. In other words, the page isn't aware of it. If you use Fullscreen API terminologies, you could for example, simply check if the document has an associated fullscreen element. This would allow for a clearer specification and a stronger compatibility.

From @Hzj-jie on March 19, 2017 23:47

Once a page is allowed to request keys, the requested keys should not be intercepted by the browser. i.e. Browser should always forward the reserved keys to the webpage directly.
For example, if the page requested "W" key, ctrl + W should not close the page.

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

As this spec was not yet adopted by any WG, should it be moved to the WICG? If so, it should probably use the CG-DRAFT status, not "ED".

You need to queue a task to update this. Currently the way you've written things the "in parallel" thread could update it, then hang for seconds, then add another key, etc. That wouldn't give very deterministic behavior.

Per discussion around lock() vs. lock(['SpecificKey']), we should include a blurb about using a targeted lock call for most websites and only calling lock() (all keys) when required. In this section we should also note how the UX should be modified if ESC is locked or not.

You redefine how dispatching key events works. Please make sure that's tightly coupled with the relevant prose in UI Events (it might be that such prose there is still lacking, I recommend encouraging the editors to finally add it if so). Otherwise we'll just end up with a giant mess and nobody being really sure in what order things actually happen.

From @dtapuska on March 29, 2017 14:18

Will anyone want actually mapped keys? Not specifically games or chromoting (where the keyboard layout is irrevlant to the webpage). But say someone wants to provide their own Ctrl-P (printing functionality). How do they know that on dvorak keyboard they need to actually register the 'R' in this API to get that functionality? But on a qwerty keyboard they use 'P'.

The fact that the page doesn't know the current keyboard layout and when the keyboard layout changes can be difficult to implement that functionality on top of this API. Perhaps these aren't cases we need to solve.

@smaug---- Probably someone from Gecko might have some feedback on this proposal.

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

One thing I didn't come across while reading the proposal was the ability to capture the X buttons on the mouse. Mice these days have at least two X buttons, usually used to signal back or forward navigation in the browser.

They are indeed Virtual Key Codes, however I'm not sure if standard keyboard hooks detect them. They are posted the application as WM_XBUTTONDOWN and WM_XBUTTONUP.

Seeing as games can use them in more native environments, the ability to lock them for use in the browser would be useful.

From @dtapuska on March 29, 2017 13:48

This seems a little odd given what is currently on the Navigator object (there aren't any functions and most of values are only readonly). Not sure what the motivation to add it to the Navigator object is.

@foolip Do you have any opinion?

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

The fullscreen API includes a flag which can be applied to an iFrame which allows code executing in the iFrame context to request fullscreen. Spec: https://fullscreen.spec.whatwg.org/#iframe-fullscreen-flag

Is this something we would want to do as a future extension to the KeyboardLock spec?

The scenario would be a site that hosts a game in an iframe which has the ability to request fullscreen. The game code could also request the set of keyboardkeys it requires while in fullscreen mode. Otherwise the hosting site would have to request Keyboard lock on its behalf.