- From: Rick Byers via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 Jan 2017 20:35:39 +0000
- To: public-pointer-events@w3.org
@schieb: thanks for the suggestion. We discussed a much more permissive (but more hacky) form of that restriction in [the chromium bug](https://bugs.chromium.org/p/chromium/issues/detail?id=606896) and Microsoft folks were concerned that it would break some legitimate use cases (eg. where one frame `postMessage's` to another to tell it to capture a pointer). For example, there's a scenario in Google Feedback where you can drag on a resize handle inside the feedback frame itself which delegates to the containing frame to actually resize the iframe container in response to that dragging. That's done today by just postMessaging the pointer position, but would be simpler and more efficient if the inner frame could just tell it's containing frame that it's time to capture the pointer over it's iframe element. But I'm not really convinced that these use cases are valuable enough to justify the complexity of needing a solution for sandboxed iframes. One idea is to add a metric to Chrome to track what fraction of `setPointerCapture` calls today would violate a restriction like that. If it's essentially zero, then there shouldn't be much harm in having such a restriction for now, and exploring lifting it only if we get reports of concrete use cases people want to enable but can't. Thoughts? -- GitHub Notification of comment by RByers Please view or discuss this issue at https://github.com/w3c/pointerevents/issues/16#issuecomment-271986248 using your GitHub account
Received on Wednesday, 11 January 2017 20:35:45 UTC