Define active document for the active pointers#300
Conversation
Limit the pointer capture API scope to only work when it is called on the document who got the last event in the given pointer stream.
|
@smaug---- @graouts Just something to remember regarding an embedded iframe. When the pointer moves on top of an embedded iframe the embedder will receive one 'pointerover' event on the iframe element and never receives a 'pointerleave' while the pointer is on top of the embedded iframe. That's why I didn't rely on the boundary events in this pull request. |
|
|
||
| <p>If this is a <code>pointerdown</code> event, the associated device is a direct manipulation device and the target is an <code>Element</code>, then <a href="#setting-pointer-capture">set pointer capture</a> for this <code>pointerId</code> to the target element as described in <a>implicit pointer capture</a>. | ||
| <p>If the <var>eventTarget</var> is an <code>Element</code>, then let <var>targetDocument</var> be <var>eventTarget</var>'s <a href="https://dom.spec.whatwg.org/#concept-node-document">node document</a> [[!DOM4]]. | ||
| Otherwise, <var>eventTarget</var> is a <code>Window</code> object, |
There was a problem hiding this comment.
When can the eventTarget be Window?
There was a problem hiding this comment.
That's a good question. I don't know that this could ever happen due to pointer capture.
There was a problem hiding this comment.
I have been thinking about this and couldn't come up with any case. As a matter of fact Chrome code certainly never targets the window directly. Note that Window will be in the propagation path but never is the target if the event.
I have added the window case for the case of completion as it was different to get the document from a window object. But I'll remove it to be more precise as we know it doesn't happen at least with the current state of the things.
There was a problem hiding this comment.
Also pointer capture cannot cause that. As pointer capture API is from the Element idl and window doesn't inherit from that in anyway.
| <h2>Firing events using the <code>PointerEvent</code> interface</h2> | ||
| <p>To <dfn>fire a pointer event named e</dfn> means to <dfn>fire an event named e</dfn> as defined in [[!DOM4]] with an event using the <a>PointerEvent</a> interface whose attributes are set as defined in <a href="#pointerevent-interface"><code>PointerEvent</code> Interface</a> and <a href="#attributes-and-default-actions">Attributes and Default Actions</a>.</p> | ||
| <p>If the event is not <code>gotpointercapture</code> or <code>lostpointercapture</code>, run <a href="#process-pending-pointer-capture">Process Pending Pointer Capture</a> steps for this <code>PointerEvent</code>. | ||
| <p>If the <var>event</var>'s <code>type</code> is not <code>gotpointercapture</code> or <code>lostpointercapture</code>, run <a href="#process-pending-pointer-capture">Process Pending Pointer Capture</a> steps for this <code>PointerEvent</code>. |
There was a problem hiding this comment.
Sorry to be a stickler, but this change, while welcome, is unrelated to issue #291.
| <p>If the <var>event</var>'s <code>type</code> is not <code>gotpointercapture</code> or <code>lostpointercapture</code>, run <a href="#process-pending-pointer-capture">Process Pending Pointer Capture</a> steps for this <code>PointerEvent</code>. | ||
|
|
||
| <p>The target object at which the event is fired is determined as follows: | ||
| <p>The <var>eventTarget</var> object at which the <var>event</var> is fired is determined as follows: |
There was a problem hiding this comment.
Same for this change, this should be in a separate PR.
| <li>If the <a>pointer capture target override</a> has been set for the pointer, set the target to <a>pointer capture target override</a> object.</li> | ||
| <li>Otherwise, set the target to the object returned by normal hit test mechanisms (out of scope for this specification).</li> | ||
| <li>If the <a>pointer capture target override</a> has been set for the pointer, set the <var>eventTarget</var> to <a>pointer capture target override</a> object.</li> | ||
| <li>Otherwise, set the <var>eventTarget</var> to the object returned by normal hit test mechanisms (out of scope for this specification).</li> |
|
|
||
| <p>If this is a <code>pointerdown</code> event, the associated device is a direct manipulation device and the target is an <code>Element</code>, then <a href="#setting-pointer-capture">set pointer capture</a> for this <code>pointerId</code> to the target element as described in <a>implicit pointer capture</a>. | ||
| <p>If the <var>eventTarget</var> is an <code>Element</code>, then let <var>targetDocument</var> be <var>eventTarget</var>'s <a href="https://dom.spec.whatwg.org/#concept-node-document">node document</a> [[!DOM4]]. | ||
| Otherwise, <var>eventTarget</var> is a <code>Window</code> object, |
There was a problem hiding this comment.
That's a good question. I don't know that this could ever happen due to pointer capture.
mustaqahmed
added
needs-wpt
|
We need a WPT that requests pointer-capture on an element from a different frame. |
|
We now have WPT coverage for this: pointerevent_pointercapture_in_frame.html. |
mustaqahmed
removed
the
needs-wpt
6 participants
Limit the pointer capture API scope to only work
when it is called on the document who got the
last event in the given pointer stream.
Fixes #291
💥 Error: 500 Internal Server Error 💥
PR Preview failed to build. (Last tried on Nov 4, 2019, 9:35 PM UTC).
More
PR Preview relies on a number of web services to run. There seems to be an issue with the following one:
�� Spec Generator - Spec Generator is the web service used to build specs that rely on ReSpec.
🔗 Related URL
If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.