Skip to content

Remove redundant user activation text from PointerLock spec. #76

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Nov 15, 2021
Merged

Remove redundant user activation text from PointerLock spec. #76

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
9a40c66
Remove redundant user activation text from PointerLock spec.
mustaqahmed Oct 26, 2021
632a20a
Fix refs.
mustaqahmed Nov 5, 2021
b953997
Fix refs after HTML spec update.
mustaqahmed Nov 9, 2021
230bdc5
Typo.
mustaqahmed Nov 15, 2021
ff34935
Remove obsolete MSDN link.
mustaqahmed Nov 15, 2021
438a679
More specific text.
mustaqahmed Nov 15, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
104 changes: 39 additions & 65 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -119,9 +119,9 @@ <h2>
movements can be tracked indefinitely in any direction.
</p>
<p>
Pointer Lock is related to Mouse Capture [[MSDN-SETCAPTURE]]
[[MDN-SETCAPTURE]] (Mouse Capture is unspecified: bug <a href=
"https://www.w3.org/Bugs/Public/show_bug.cgi?id=14600">14600</a>).
Pointer Lock is related to Mouse Capture [[MDN-SETCAPTURE]] (Mouse
Capture is unspecified:
bug <a href="https://www.w3.org/Bugs/Public/show_bug.cgi?id=14600">14600</a>).
Capture provides continued event delivery to a target element while a
mouse is being dragged, but ceases when the mouse button is released.
Pointer Lock differs by being persistent, not limited by screen
Expand All @@ -143,28 +143,6 @@ <h2>
impacted.
</p>
</section>
<section>
<h2>
Glossary
</h2>
<dl>
<dt>
<dfn>Engagement gesture</dfn>
</dt>
<dd>
An event generated by the user agent as a result of user interaction
processed by the user agent to interact with the page. e.g.
<code>click</code>, but not <code>mousemove</code>. Engagement
gestures are defined by the events in the list of <a>activation
triggering input event</a> with the addition of <code>keypress</code>
and <code>keyup</code> events. Note that operating system level
accessibility and internationalization features may intercept
gestures before the user agent processes them for interaction with a
page. E.g. multiple key press codes used to enter an extended
international character.
</dd>
</dl>
</section>
<section>
<h2>
<code>pointerlockchange</code> and <code>pointerlockerror</code> Events
Expand Down Expand Up @@ -213,49 +191,46 @@ <h2>
<p>
Requests that the pointer be locked to a DOM element
<dfn>target</dfn>. The <a>user agent</a> determines if pointer lock
state will be entered and upon lock state change or error must send
state will be entered, and upon lock state change or error MUST send
either a <a>pointerlockchange</a> or <a>pointerlockerror</a> event
respectively.
</p>
<p>
Pointer lock must not succeed if the document object's
[=Document/active sandboxing flag set=] has the <a>sandboxed
pointer lock browsing context flag</a> set.
Pointer lock MUST fail if the document object's [=Document/active
sandboxing flag set=] has the <a>sandboxed pointer lock browsing
context flag</a> set.
</p>
<p>
Pointer lock must not succeed unless the <a>target</a>'s
Pointer lock MUST fail unless the <a>target</a>'s
<a>shadow-including root</a> is the <a>active document</a> of a
[=Document/browsing context=] which is (or has an <a>ancestor
browsing context</a> which is) in focus by a window which is in
focus by the operating system's window manager. The <a>target</a>
element and its [=Document/browsing context=] need not be in focus.
</p>
<p>
If a user has exited pointer lock via the <a>default unlock
gesture</a>, or pointer lock has not previously been entered for
this document, an event generated as a result of an <a>engagement
gesture</a> must be received by the document before
{{requestPointerLock()}} will succeed.
Pointer lock is a <a>transient activation-gated API</a>, therefore a
{{requestPointerLock()}} call MUST fail if the <a>relevant global
object</a> of [=this=] does not have <a>transient activation</a>.
This prevents locking upon initial navigation or re-acquiring lock
without user's attention.
</p>
<p>
A {{requestPointerLock()}} call immediately after the <a>default
unlock gesture</a> MUST fail even when <a>transient activation</a>
is available, to prevent malicious sites from acquiring an
unescapable locked state through repeated lock attempts. On the
other hand, a {{requestPointerLock()}} call immediately after a
programmatic lock exit (through a {{Document/exitPointerLock()}}
call) MUST succeed when <a>transient activation</a> is available, to
enable applications to move frequently between interaction modes,
possibly through a timer or remote network activity.
</p>
<aside class="note" data-link-for="Document">
<p>
This ensures a user can leave a document that constantly attempts
to lock the pointer. The document will be blocked from locking
upon initial navigation or re-acquiring lock unless the user
re-engages directly with the document.
</p>
<p>
Conversely, if pointer lock is exited via {{exitPointerLock()}}
no <a>engagement gesture</a> is required to reenter pointer lock.
This enables applications that frequently move between
interaction modes, and ones that may do so based on a timer or
remote network activity.
</p>
<p data-link-for="Element">
Pointer lock is commonly combined with fullscreen [[FULLSCREEN]],
and if an <a>engagement gesture</a> is used to enter fullscreen
it is sufficient for a subsequent {{requestPointerLock()}}.
</p>
<aside class="note">
When a single <a>user activation</a> initiates both pointer lock and
fullscreen [[FULLSCREEN]], the {{requestPointerLock()}} call
succeeds only when it is made before a fullscreen request because
fullscreen is a <a>transient activation-consuming API</a>.
</aside>
<p>
If any element (including this one), whose <a>shadow-including
Expand Down Expand Up @@ -429,7 +404,7 @@ <h2>
equivalent to the sum of all {{movementX}} {{movementY}}/code&gt;
events after <code>earlierEvent</code>, with the exception of when
screenX can not be updated because the pointer is clipped by the
user agent screen boundaries.
<a>user agent</a> screen boundaries.
</p>
<p>
{{movementX}}/{{movementY}} must be updated regardless of pointer
Expand Down Expand Up @@ -659,10 +634,10 @@ <h2>
<p>
Games that use pointer lock may desire a traditional UI and system
cursor while players prepare in a game lobby. Games usually start
after a short timer when all players are ready. Ideally the game
could then switch to pointer lock mode without requiring an
<a>engagement gesture</a>. Players should be able to seamlessly move
from the game lobby into game navigation.
after a short timer when all players are ready. Ideally the game could
then switch to pointer lock mode without a <a>user
activation</a>. Players should be able to seamlessly move from the
game lobby into game navigation.
</p>
</section>
<section>
Expand All @@ -689,7 +664,7 @@ <h2>
to interact with.
</li>
<li>Pointer Lock will remove the ability of a user to interact with
user agent and operating system controls
<a>user agent</a> and operating system controls
</li>
<li>Pointer Lock can be called repeated by script after user exits
pointer lock, blocking user from meaningful progress.
Expand All @@ -716,16 +691,15 @@ <h2>
</li>
<li>Persistent display of escape instructions can be provided.
</li>
<li>Repeated escapes of pointer lock can signal <a>user agent</a> to
not re-lock the pointer without more specific <a>engagement
gesture</a>, e.g. similar to how Chrome suppresses repeated alert()
calls.
<li>Repeated escapes of pointer lock can signal <a>user agent</a> to not
re-lock the pointer without more specific user action, e.g. similar to
how Chrome suppresses repeated alert() calls.
</li>
<li>Changing to new tabs, windows, or any other action that causes a
page to lose focus will exit pointer lock.
</li>
<li>Pointer lock can only be engaged when the window is in focus in the
user agent and operating system.
<a>user agent</a> and operating system.
</li>
</ul>
<p>
Expand Down