New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 680163 link

Starred by 1 user
Status: Assigned
Owner:
dtapu...@chromium.org
Cc:
█ mkwst@chromium.org
nzolghadr@chromium.org
iclell...@chromium.org
dtapu...@chromium.org
mustaq@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

Add allow-pointer-capture sandboxed iframe flag

Project Member Reported by rbyers@chromium.org, Jan 11 2017 
See discussion at https://github.com/w3c/pointerevents/issues/16 and in issue 606896.

As pointer events gain adoption there is greater risk that sandboxed iframes may come to depend on using setPointerCapture.  Talking with dtapuska@ we think we should just follow the pattern of allow-pointer-lock (or it's feature-policy-centric future) and add allow-pointer-capture.

Comment 1 by rbyers@chromium.org, Jan 11 2017

Cc: scheib@chromium.org
Summary: Add allow-pointer-capture sandboxed iframe flag (was: Add allow-pointer-lock sandboxed iframe flag)
/cc scheib@ in case he's got any reason why we shouldn't just copy the pattern used by "allow-pointer-lock"

Comment 2 by scheib@chromium.org, Jan 11 2017 

I've engaged in discussion on https://github.com/w3c/pointerevents/issues/16 - initially pointing out that I don't think allow-pointer-capture is necessary if entering capture is only possible for elements that are receiving events from a pointer.

Comment 3 by dtapu...@chromium.org, Jan 12 2017

Labels: Hotlist-Input-Dev
Owner: dtapu...@chromium.org
Status: Assigned (was: Unconfirmed)
Assigning to myself for now until we make a decision of the approach we want to take.

Comment 4 by scheib@chromium.org, Jan 9 2018

Cc: -scheib@chromium.org
►

Sign in to add a comment