21749 2013-04-19 06:28:04 +0000 Setting a capture on an offshore element 2014-06-02 22:25:21 +0000 1 1 1 Unclassified PointerEventsWG Pointer Events specification unspecified PC Windows NT RESOLVED FIXED P2 normal --- 1 jrossi jrossi art.barstow francois.remy.dev nekr.fabula public-pointer-events rbyers public-pointer-events-bugzilla oldest_to_newest 86383 0 jrossi 2013-04-19 06:28:04 +0000 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. 86384 1 jrossi 2013-04-19 06:28:24 +0000 This will be considered a CR issue. 102186 2 jrossi 2014-03-11 05:20:10 +0000 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. 102205 3 rbyers 2014-03-11 15:54:28 +0000 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. 103859 4 jrossi 2014-04-15 05:11:44 +0000 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." 103860 5 jrossi 2014-04-15 05:24:03 +0000 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 107158 6 jrossi 2014-06-02 22:25:21 +0000 Fixed: https://dvcs.w3.org/hg/pointerevents/rev/734470902d30 Per resolution: http://www.w3.org/2014/04/15-pointerevents-minutes.html#item04