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

@foolip commented on this pull request.

I noticed a problem and am wondering about the more general idea with nested fullscreen scenarios. In both "`requestFullscreen(options)` method steps" and the "exit fullscreen" algorithm, the flag is only set/unset on a single element. But in nested scenarios, there's no guarantee that those elements are the same. Consider this simple case:

```js
elm1.onclick = () => { elm1.requestFullscreen({ keyboardLock: "browser" }); }
elm2.onclick = () => { elm2.requestFullscreen(); }
```

If the elements are clicked in order and later something triggers "fully exit fullscreen", the keyboard lock flag will remain set on _elm1_.

> @@ -177,7 +178,27 @@ steps:
 <p class=note>These steps integrate with the <a for=/>event loop</a> defined in HTML. [[!HTML]]
 </div>
 
+<hr>
+
+<p>All <a>elements</a> have an associated <dfn>keyboard lock flag</dfn>. Unless stated otherwise it
+is unset.
+
+<p>A <a>document</a> has <dfn>keyboard lock</dfn> active when its <a>fullscreen element</a> is not
+null and the <a>fullscreen element</a>'s <a>keyboard lock flag</a> is set, and inactive otherwise.
+
+<div algorithm>
+  <p>To <dfn>release the keyboard lock</dfn> for a <a>document</a> <var>document</var>, run these
+  steps:
+
+  <ol>
+    <li><p>If <var>document</var>'s <a>fullscreen element</a> is null, then return.

In the case where the fullscreen element is removed, I think the keyboard lock flag will remain set, because of this early return.

Is there any reason to not unconditionally unset the flag?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fullscreen/pull/232#pullrequestreview-4220634151
You are receiving this because you are subscribed to this thread.

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