- From: Jacob Rossi <Jacob.Rossi@microsoft.com>
- Date: Mon, 1 Oct 2012 20:27:58 +0000
- To: "brandon.wallace@yahoo.com" <brandon.wallace@yahoo.com>, "public-pointer-events@w3.org" <public-pointer-events@w3.org>
- Message-ID: <D0BC8E77E79D9846B61A2432D1BA4EAE066A1863@TK5EX14MBXC286.redmond.corp.microsoft.>
From: Brandon Wallace <brandon.wallace@yahoo.com<mailto:brandon.wallace@yahoo.com?Subject=Re%3A%20What%20is%20the%20scope%20of%20pointerCapture%3F&In-Reply-To=%253C1348842447.24933.YahooMailNeo%40web113607.mail.gq1.yahoo.com%253E&References=%253C1348842447.24933.YahooMailNeo%40web113607.mail.gq1.yahoo.com%253E>> Date: Fri, 28 Sep 2012 07:27:27 -0700 (PDT) Message-ID: <1348842447.24933.YahooMailNeo@web113607.mail.gq1.yahoo.com> To: "public-pointer-events@w3.org<mailto:public-pointer-events@w3.org?Subject=Re%3A%20What%20is%20the%20scope%20of%20pointerCapture%3F&In-Reply-To=%253C1348842447.24933.YahooMailNeo%40web113607.mail.gq1.yahoo.com%253E&References=%253C1348842447.24933.YahooMailNeo%40web113607.mail.gq1.yahoo.com%253E>" <public-pointer-events@w3.org<mailto:public-pointer-events@w3.org?Subject=Re%3A%20What%20is%20the%20scope%20of%20pointerCapture%3F&In-Reply-To=%253C1348842447.24933.YahooMailNeo%40web113607.mail.gq1.yahoo.com%253E&References=%253C1348842447.24933.YahooMailNeo%40web113607.mail.gq1.yahoo.com%253E>> > The setPointerCapture() and releasePointerCapture() are rather interesting and I can think of quite a few edge cases. But I think many of them come down to a question of capture scope. What exactly is the scope of the capture? > > - Is it the pointer events that would ordinarily go to a child of element.documentParent? (events are not delivered if the pointer leaves the boundaries of the element's document) > - Is it the pointer events that would ordinarily go to a child of the top-most document containing the element (something like element.documentParent.window.top.document). (events are delivered even if the pointer leaves the boundaries of the element's parent document, events stop being delivered if they leave the boundaries of the top-most containing document). > - Is it the pointer events that would ordinarily go to a child of the user agent (The pointer event is delivered even if it leaves the topmost window and travels around the UI of the user agent itself, events stop being seen if the pointer leaves the boundaries of the user agent) > - Is it all pointer events for this pointer reported by the hardware (The pointer event is delivered even if the pointer leaves the boundaries of the user agent, e.g. the pointer can wander outside the browser window to anywhere on the device and the events are still delivered to the target element). > - Something else entirely? > As an author, I have a preference for the last one. It seems to match what happens with mouse events (after my web page receives a mousedown event, it continues receiving mousemove and mouseup events even if the mouse is outside the browser window). > Good, because that’s what we implemented. :-) > If the capture scope extends beyond element.documentParent, then what if code in a child iframe uses this API to maliciously capture all active pointers (including the mouse which is considered active even when not pressed)? Can such malicious code steal all pointer events from the rest of the user agent, possibly even the entire user's desktop? This section of the spec could use some better text and more detail. Here’s what we do: 1. You can only capture a pointer if buttons>0 (e.g. mouse button is down, finger is on screen, or pen tip is on digitizer). So you can’t just spy on interactions with UI outside your scope. 2. Once you set capture to a pointer, its target property will always be the capturing element. So while you can monitor movement of the pointer outside your contact (again, only while it’s down), you can’t get references to elements, etc. 3. Capture is automatically release when the pointer comes up (e.g. buttons==0). > Does the element still receive the pointer events if it is removed from the DOM tree (via removeChild)? No. > Thanks, > Brandon
Received on Monday, 1 October 2012 20:28:34 UTC