This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 21749 - Setting a capture on an offshore element
Summary: Setting a capture on an offshore element
Status: RESOLVED FIXED
Alias: None
Product: PointerEventsWG
Classification: Unclassified
Component: Pointer Events specification (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Jacob Rossi [MSFT]
QA Contact: Pointer Events Bugzilla list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-19 06:28 UTC by Jacob Rossi [MSFT]
Modified: 2014-06-02 22:25 UTC (History)
5 users (show)

See Also:


Attachments

Description Jacob Rossi [MSFT] 2013-04-19 06:28:04 UTC
From Francois Remy: http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0084.html


Here’s a test case for your consideration where, I believe, IE10 is distant from the official specification:


<!doctype html>
<html onmspointerdown="eatPointer(event.pointerId)" onmspointermove="if(event.button>=0) console.log(event.clientX+','+event.clientY)">
 <head>
  <title>Some pointer events test</title>
  <script>
   var x = document.createElement("div");
   function eatPointer(id) {
    x.msSetPointerCapture(id); // will throw
   }
  </script>
 </head>
 <body>
 </body>
</html>


I believe the spec does not say the capture should fail, and therefore it should not. That would mean, however, that the capture may end up happening on a different window than the one the event was fired for, something which can be a problem.
Comment 1 Jacob Rossi [MSFT] 2013-04-19 06:28:24 UTC
This will be considered a CR issue.
Comment 2 Jacob Rossi [MSFT] 2014-03-11 05:20:10 UTC
It's generally expected that DOM Events do not fire at orphaned elements. In particular, this is because you can't form a proper event path for dispatch.

However, because the capture APIs exists, I do see that this could lead a developer to believe capture could redirect events to an orphaned element. I'd propose we add this exception to the spec.

My proposal is to add a step to the setPointerCapture() method that reads:

If the Element on which this method is invoked does not participate in its ownerDocument's tree, throw an exception with the name "InvalidStateError".

Happy to let folks bikeshed on the specific exception to be thrown (IE currently, oddly enough, does not throw a named exception in this case). :-)

I'm also not 100% confident on the spec language to denote an orphaned element. Will want to check with someone like AnneVK to confirm.
Comment 3 Rick Byers 2014-03-11 15:54:28 UTC
Note we agreed we also need to specify what happens when an element that has capture is removed.  I believe Jacob said he'd provide more details on IE behavior.
Comment 4 Jacob Rossi [MSFT] 2014-04-15 05:11:44 UTC
It doesn't make sense to try to fire a lostpointercapture event in the case where the capture node is removed from the tree (events don't typically fire on nodes not in the tree). Capture should just get implicitly cleared for the pointer and hit testing resumes if the pointer is still producing events.

Given the proposed steps in comment 5 of bug 24971 [1], this can be accomplished by adding this to Section 10.3:

"If the 'pointer capture target override' is removed from the document tree, clear the 'pending pointer capture' and 'pointer capture target override' nodes. No lostpointercapture event is fired in this scenario."
Comment 5 Jacob Rossi [MSFT] 2014-04-15 05:24:03 UTC
Rereading the minutes from 3/11 [1], the proposal was made that, when the capture node is removed from the tree, a lostpointercapture event be fired at the document.  That seems reasonable to me and it looks like there was consensus. Therefore, I propose we make the change described in Comment 2 plus add this to Section 10.3:

"If the 'pointer capture target override' node is removed from the document tree, clear the 'pending pointer capture' and 'pointer capture target override' nodes and fire a Pointer Event named lostpointercapture at the document."


[1] http://www.w3.org/2014/03/11-pointerevents-minutes.html#item03