Re: [whatwg/fullscreen] Add keyboard locking option (PR #232)

zcorpan left a comment (whatwg/fullscreen#232)

Happy to have a call.

> FF151 adds support for this interface as per this spec. I'm supposed to document it - tracking bug is [mdn/content#43868](https://github.com/mdn/content/issues/43868)
> 
> However this update hasn't been accepted, and there seems to be some questions about the implementation in the discussion. As such the implementations will be "non-standard" which makes documenting from a baseline hard.

I would expect this can land pretty soon, though.

> Can you help me by advising/confiming on the following?
> 
>   1. From https://github.com/whatwg/fullscreen/pull/232/changes#r2754161239 Safari seems to have an extra mode option `system`, but is otherwise the same.
>        
>      * Do `none` and `browser` on Safari mean the same thing as in the spec.

I think so.

>      * What does "system" mode mean/how does it differ from `browser`.

From what I can tell, it doesn't do anything in WebKit (so is the same as `none`).

>   2. The update indicates that browsers should provide alternative mechanisms for exiting fullscreen.
>        
>      * AIUI the methods are not mandated right?

"should" is a normative requirement, see RFC 2119. The specific alternative mechanisms are up to the UA.

>      * The FF implementation uses long-press Escape. Do we know if Safari and Chrome use or intend to use long-press escape too as the exit-fullscreen key?

In Chrome (with `navigator.keyboard.lock(); el.requestFullscreen()`), long-press esc (1500ms in my testing) exits fullscreen.

In Safari with `el.requestFullscreen({keybaordLock: "browser"})`, long-press esc (500ms in my testing) exits fullscreen.
          
>        * If so, would that likely become mandated by the spec?

It's not mandated currently in this PR.

>      * What is the broad thinking for Android - we use `browser` mode for that, but some other key can be the escape key?

I think there's not the same need for keyboard lock on Android, so possibly it could be equivalent to "none".

> 
>   3. The spec says:
>      > may either have no action while [=keyboard lock=] is active, or it could still have the same action but allow the web page to call {{Event/preventDefault()}} to cancel the action.
>        
>        
>      Doesn't that mean that a web application will always have to call `preventDefault()` to use a key that might be used by something else normally - because it can't know from whether the event default action has been disabled or not?

Yes.

We could maybe standardize that the esc key should have no action when keyboard lock is active.

 
>   4. Firefox release note states of the implementation "This prevents the Esc key from causing the element to leave fullscreen (instead, a long-press is required), and some formerly-reserved browser hotkeys are allowed to be default-prevented."
>        
>      * Is the Esc key change "standard"? I mean do all browsers use Esc normally for leaving fullscreen mode (is that in the spec?) . I guess this is really back to point 3, trying to give users a flavour of what they need to call `preventDefault()` for, and what is done for them.

All desktop browsers as far as I know use the esc key for exiting fullscreen. In practice, Safari currently requires `preventDefault()` for the esc key when keyboard lock is active.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fullscreen/pull/232?email_source=notifications&email_token=ACLYVMJJTKFZA66IMVVTBJ34XCKETA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRZGUZDSNRSGQZ2M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOS2XA4S7MNXW23LFNZ2F633QMVXF6Y3MNFRWW#issuecomment-4295296243
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fullscreen/pull/232/c4295296243@github.com>