- From: James <notifications@github.com>
- Date: Tue, 29 Sep 2020 15:28:11 -0700
- To: w3c/pointerlock <pointerlock@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/pointerlock/pull/49/review/478015905@github.com>
@JamesHollyer commented on this pull request.
Thanks again Domenic! Please check out these changes. I think it is starting to come along.
> + error in changing state. They are named <dfn>pointerlockchange</dfn>
+ and <dfn>pointerlockerror</dfn>. If pointer lock is entered or exited
+ for any reason a <a>pointerlockchange</a> event must be sent.
+ </p>
+ <p>
+ <a>User agents</a> must deliver these events by <a data-lt=
+ "queue a task">queuing a task</a> to <a>fire an event</a> of the
+ appropriate name with its <code>bubbles</code> attribute [[DOM]] set to
+ false to the pointer lock <a>target</a> element's <a>node document</a>.
+ </p>
+ <p class="note">
+ Magnification software increases the size of content on the screen. It
+ uses the mouse to move the magnified point of focus around. When a
+ pointer lock is initiated, the magnification software needs to switch
+ to using the keyboard to move the magnified point of focus around
+ instead. When a pointerlockchange event is fired, web browsers
done
> - document=].
- </p>
- <p class="note">
- Magnification software increases the size of content on the screen. It
- uses the mouse to move the magnified point of focus around. When a
- pointer lock is initiated, the magnification software needs to switch
- to using the keyboard to move the magnified point of focus around
- instead. When a pointerlockchange event is fired, web browsers
- therefore need to make sure the event is communicated to assistive
- technologies like screen magnifiers.
- </p>
+ <section>
+ <h3>
+ The <dfn>Pointer Lock State</dfn> Definition
+ </h3>
+ <p><a>Pointer Lock State</a> is the state where a single DOM element, which
Done.
> + <section>
+ <h3>
+ The <dfn>Pointer Lock State</dfn> Definition
+ </h3>
+ <p><a>Pointer Lock State</a> is the state where a single DOM element, which
+ we will call the <dfn>pointer-lock target</dfn>, receives all mouse events and the cursor
+ is hidden.</p>
+ <p>
+ Once in the <a>Pointer Lock State</a> the <a>user agent</a> has a
+ <a>pointer-lock target</a> and a set of <a>PointerLockOptions</a>. The
+ <a>pointer-lock target</a> must receive all relevant user generated
+ {{MouseEvent}} events (for example: `mousemove`, `mousedown`, `mouseup`,
+ `click`, and `wheel`) [[ui-events]]. No other elements may receive these
+ events while in <a>Pointer Lock State</a>. Events that require the concept of
+ a mouse cursor must not be dispatched (for example: `mouseover`, `mouseout`,
+ `drag`, and `drop`).
I am not sure what you mean by "Pointer Events".
I have tried to make a thorough list of mouse events from that uievents page.
> - pointer lock is initiated, the magnification software needs to switch
- to using the keyboard to move the magnified point of focus around
- instead. When a pointerlockchange event is fired, web browsers
- therefore need to make sure the event is communicated to assistive
- technologies like screen magnifiers.
- </p>
+ <section>
+ <h3>
+ The <dfn>Pointer Lock State</dfn> Definition
+ </h3>
+ <p><a>Pointer Lock State</a> is the state where a single DOM element, which
+ we will call the <dfn>pointer-lock target</dfn>, receives all mouse events and the cursor
+ is hidden.</p>
+ <p>
+ Once in the <a>Pointer Lock State</a> the <a>user agent</a> has a
+ <a>pointer-lock target</a> and a set of <a>PointerLockOptions</a>. The
Makes sense.
> + </dd>
+ <dt>
+ <dfn>unadjustedMovement</dfn> member
+ </dt>
+ <dd>
+ <p>
+ If this value is set to `true`, then the pointer movements will
+ not be affected by the underlying platform modications such as
+ mouse accelaration.
+ </p>
+ </dd>
+ </dl>
+ </section>
+ <section>
+ <h3>
+ `"pointerlockchange"` and `"pointerlockerror"` Events
done
> + <dfn>unadjustedMovement</dfn> member
+ </dt>
+ <dd>
+ <p>
+ If this value is set to `true`, then the pointer movements will
+ not be affected by the underlying platform modications such as
+ mouse accelaration.
+ </p>
+ </dd>
+ </dl>
+ </section>
+ <section>
+ <h3>
+ `"pointerlockchange"` and `"pointerlockerror"` Events
+ </h3>
+ <p class="note">
done
> + instead. When a pointerlockchange event is fired, web browsers
+ therefore need to make sure the event is communicated to assistive
+ technologies like screen magnifiers.
+ </p>
+ </section>
+ <section>
+ <h3><dfn>Exit Pointer Lock</dfn></h3>
+ <p>
+ The process of exiting pointer lock is as follows:
+ <ol>
+ <li>
+ <a href=https://dom.spec.whatwg.org/#concept-event-fire">Fire an event</a> named
+ <a>pointerlockchange</a> at <a>this</a>'s
+ <a href="https://dom.spec.whatwg.org/#concept-node-document">node document</a> on the
+ <a href="https://html.spec.whatwg.org/multipage/webappapis.html#user-interaction-task-source">
+ User Interaction task source</a>
Per our discussion I changed this to Queue a Task and in the method definition I simply referenced this algorithm and passed in the element.
Please take a look and let me know if you think this is in a good state now.
> + <h3><dfn>Exit Pointer Lock</dfn></h3>
+ <p>
+ The process of exiting pointer lock is as follows:
+ <ol>
+ <li>
+ <a href=https://dom.spec.whatwg.org/#concept-event-fire">Fire an event</a> named
+ <a>pointerlockchange</a> at <a>this</a>'s
+ <a href="https://dom.spec.whatwg.org/#concept-node-document">node document</a> on the
+ <a href="https://html.spec.whatwg.org/multipage/webappapis.html#user-interaction-task-source">
+ User Interaction task source</a>
+ </li>
+ <li>
+ The system mouse cursor must be displayed again and positioned at
+ the same location that it was when pointer lock was entered (the
+ same location that is reported in <code>screenX</code>,
+ <code>screenY</code>, when the pointer is locked).
Added a |cursor position| variable to the user agent and referenced that when entering and exiting pointer lock. I also removed this from the exitPointerLock() method definition.
> + The process of exiting pointer lock is as follows:
+ <ol>
+ <li>
+ <a href=https://dom.spec.whatwg.org/#concept-event-fire">Fire an event</a> named
+ <a>pointerlockchange</a> at <a>this</a>'s
+ <a href="https://dom.spec.whatwg.org/#concept-node-document">node document</a> on the
+ <a href="https://html.spec.whatwg.org/multipage/webappapis.html#user-interaction-task-source">
+ User Interaction task source</a>
+ </li>
+ <li>
+ The system mouse cursor must be displayed again and positioned at
+ the same location that it was when pointer lock was entered (the
+ same location that is reported in <code>screenX</code>,
+ <code>screenY</code>, when the pointer is locked).
+ </li>
+ <li>
Changed this step to exiting Pointer Lock State by setting all the user agent variables to null. Let me know if you think this satisfies the requirements.
> - relevant user generated {{MouseEvent}} events (for example:
- `mousemove`, `mousedown`, `mouseup`, `click`, and `wheel`)
- [[ui-events]] to the <a>target</a> of pointer lock, and not fire
- mouse events to other elements. Events that require the concept of
- a mouse cursor must not be dispatched (for example: `mouseover`,
- `mouseout`, `drag`, and `drop`).
- </p>
- <p>
- In the locked state the system mouse cursor must be hidden.
- Movement and button presses of the mouse must not cause the window
- to lose focus.
- </p>
- <p>
- Synthetic mouse events created by application script act the same
- regardless of lock state.
+ RequestPointerLock() will perform the following steps:
Done.
> - <p>
- Synthetic mouse events created by application script act the same
- regardless of lock state.
+ RequestPointerLock() will perform the following steps:
+ <ol>
+ <li>
+ If the <a href="https://heycam.github.io/webidl/#this">this</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:
+ <ol>
+ 1. <a href="https://html.spec.whatwg.org/multipage/webappapis.html#queue-an-element-task">
+ Queue an element task</a> on the
+ <a href="https://html.spec.whatwg.org/multipage/webappapis.html#user-interaction-task-source">
+ User Interaction task source</a>, given this, to perform the following steps:
Done
> + [=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:
+ <ol>
+ 1. <a href="https://html.spec.whatwg.org/multipage/webappapis.html#queue-an-element-task">
+ Queue an element task</a> on the
+ <a href="https://html.spec.whatwg.org/multipage/webappapis.html#user-interaction-task-source">
+ User Interaction task source</a>, given this, to perform the following steps:
+ <ol>
+ <li>
+ <a href=https://dom.spec.whatwg.org/#concept-event-fire">Fire an event</a> named
+ <a>pointerlockerror</a> at <a>this</a>'s
+ <a href="https://dom.spec.whatwg.org/#concept-node-document">node document</a>.
+ </li>
+ <li>
+ Return <a>a promise rejected with</a> a "{{WrongDocumentError}}" {{DOMException}}.
Ok I changed this. I think I did it write. PTAL.
> + <a>pointerlockerror</a> at <a>this</a>'s
+ <a href="https://dom.spec.whatwg.org/#concept-node-document">node document</a>.
+ </li>
+ <li>
+ Return <a>a promise rejected with</a> a "{{InvalidStateError}}" {{DOMException}}.
+ </li>
+ </ol>
+ </ol>
+ </li>
+ <li>
+ If the user agent's <a>pointer-lock target</a>'s <a>shadow-including
+ root</a> is equal to <a>this</a>'s <a>shadow-including root</a> follow these steps:
+ <ol>
+ <li>
+ If this request's <a>pointerLockOptions</a> are equivalent to the user agent's current
+ <a>pointerLockOptions</a> then the <a>pointer-lock target</a>
Let me know if I did this correctly.
> + </ol>
+ </ol>
+ </li>
+ <li>
+ If the user agent's <a>pointer-lock target</a>'s <a>shadow-including
+ root</a> is equal to <a>this</a>'s <a>shadow-including root</a> follow these steps:
+ <ol>
+ <li>
+ If this request's <a>pointerLockOptions</a> are equivalent to the user agent's current
+ <a>pointerLockOptions</a> then the <a>pointer-lock target</a>
+ must be updated to this element, a <a>pointerlockchange</a>
+ event sent, and the promise must <a>resolve</a>.
+ </li>
+ <li>
+ If this request's <a>pointerLockOptions</a> are not equivalent to the user agent's current
+ <a>pointerLockOptions</a> and this request's <a>pointerLockOptions</a> are not supported:
Done. PTAL
> + <a href=https://dom.spec.whatwg.org/#concept-event-fire">Fire an event</a> named
+ <a>pointerlockerror</a> at <a>this</a>'s
+ <a href="https://dom.spec.whatwg.org/#concept-node-document">node document</a>.
+ </li>
+ <li>
+ Return <a>a promise rejected with</a> a "{{NotSupportedError}}" {{DOMException}}.
+ </li>
+ </ol>
+ </ol>
+ </li>
+ <li>
+ If this request's <a>pointerLockOptions</a> are not equivalent to the user agent's current
+ <a>pointerLockOptions</a> and this request's <a>pointerLockOptions</a> are supported the
+ user agent's <a>pointer-lock target</a> must be updated to this element, the user agent's
+ <a>pointerLockOptions</a> must be updated to this request's <a>pointerLockOptions</a>, a
+ <a>pointerlockchange</a> event sent, and the promise must <a>resolve</a>.
I tried to make it better. Let me know what you think
> + <a>pointerLockOptions</a> must be updated to this request's <a>pointerLockOptions</a>, a
+ <a>pointerlockchange</a> event sent, and the promise must <a>resolve</a>.
+ </li>
+ </ol>
+ </li>
+ <li>
+ If any element (including this one), whose <a>shadow-including
+ root</a> is same as this element's <a>shadow-including root</a>, is
+ already locked (or pending lock) the pointer lock <a>pointer-lock target</a>
+ must be updated to this element, a <a>pointerlockchange</a>
+ event sent and the promise must <a>Resolve</a>.
+ </li>
+ <li>
+ If the request was not started from an <a>engagement gesture</a> and
+ the Document has not previously released a successful Pointer Lock with
+ {{Document/exitPointerLock()}}:
I don't think so. The target can be null if that lock target was given up by calling exitPointerLock.
> + <ol type='i'>
+ <li>
+ <a href=https://dom.spec.whatwg.org/#concept-event-fire">Fire an event</a> named
+ <a>pointerlockerror</a> at <a>this</a>'s
+ <a href="https://dom.spec.whatwg.org/#concept-node-document">node document</a>.
+ </li>
+ <li>
+ Return <a>a promise rejected with</a> a "{{SecurityError}}" {{DOMException}}.
+ </li>
+ </ol>
+ </ol>
+ </li>
+ <li>
+ <dl data-dfn-for="PointerLockOptions" data-link-for=
+ "PointerLockOptions">
+ If if <a>unadjustedMovement</a> is true and the platform does not
Done.
> + Return <a>a promise rejected with</a> a "{{NotSupportedError}}" {{DOMException}}.
+ </li>
+ </ol>
+ </ol>
+ </dl>
+ <aside class="note" data-link-for="Document">
+ "{{NotSupportedError}}" {{DOMException}} should be reserved for
+ unsupported options in future iterations of this spec. That is,
+ no other error conditions should use "{{NotSupportedError}}", so
+ that web developers can use it for feature testing.
+ </aside>
+ </li>
+ <li>
+ <dl data-dfn-for="PointerLockOptions" data-link-for=
+ "PointerLockOptions">
+ If none of the above errors have occured the user agent will enter
Done.
> + Two events are used to communicate pointer lock state change or an
+ error in changing state. They are named <dfn>pointerlockchange</dfn>
+ and <dfn>pointerlockerror</dfn>.
+ </p>
+ <p class="note">
+ Magnification software increases the size of content on the screen.
+ It uses the mouse to move the magnified point of focus around. When a
+ pointer lock is initiated, the magnification software needs to switch
+ to using the keyboard to move the magnified point of focus around
+ instead. When a pointerlockchange event is fired, web browsers
+ therefore need to make sure the event is communicated to assistive
+ technologies like screen magnifiers.
+ </p>
+ </section>
+ <section>
+ <h3><dfn>Exit Pointer Lock</dfn></h3>
I referenced this in the line that says "Changing to new tabs, windows, or any other action that causes a page to lose focus will exit pointer lock."
I also added it to the recommendation that esc exits pointer lock.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/pointerlock/pull/49#pullrequestreview-478015905
Received on Tuesday, 29 September 2020 22:28:26 UTC