New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"allowed to use" active document, browsing context container... #2143

Open
zcorpan opened this Issue Dec 7, 2016 · 1 comment

Comments

2 participants
@zcorpan
Member

zcorpan commented Dec 7, 2016

In w3c/payment-request#361 (comment) @bzbarsky wrote:

What you may want to do is restrict this API to fully active documents only. But even then, walking up the creator document chain (but only until you get to a document in a toplevel browsing context) makes more sense than walking up the ancestor browsing context chain.

We don't check if document is the active document in "allowed to use".

https://html.spec.whatwg.org/#allowed-to-use currently says

  1. If document's browsing context has a browsing context container that is an iframe element with an allowattribute attribute specified, and whose node document is allowed to use the feature indicated by allowattribute, then return true.

https://html.spec.whatwg.org/#creator-browsing-context for iframe is the same as:
https://html.spec.whatwg.org/#parent-browsing-context which is defined in terms of:
https://html.spec.whatwg.org/#child-browsing-context

  • child is a nested browsing context of a browsing context container element
  • element is connected
  • element's shadow-including root's browsing context is parent

So... Shadow DOM should be considered here also. It is not clear to me yet if that is the only difference between parent browsing context and walking up the browsing context container.

@bzbarsky

This comment has been minimized.

Show comment
Hide comment
@bzbarsky

bzbarsky Dec 7, 2016

Collaborator

Here's the thing. The phrase "allowed to use" appears in HTML in three places: the definitions of the allowusermedia and allowfullscreen attrbibutes, and the definition of https://html.spec.whatwg.org/multipage/embedded-content.html#allowed-to-use

Looking at Gecko's implementation, we do have allowfullscreen that more or less follows the spec's definition (including walking up the browsing context chain, fwiw). We don't have allowusermedia.

But generally speaking, this algorithm as written means that whether the thing is allowed or not can change during the lifetime of the document, due to attribute changes on arbitrary ancestor <iframe> elements. It behaves differently from the feature policy proposals, which snapshot the parent information at document creation time...

It's possible that for allowfullscreen compat constraints mean the check has to be dynamic (though I doubt it), but for new things we should be following the feature policy approach of snapshotting the value at document creation time.

Collaborator

bzbarsky commented Dec 7, 2016

Here's the thing. The phrase "allowed to use" appears in HTML in three places: the definitions of the allowusermedia and allowfullscreen attrbibutes, and the definition of https://html.spec.whatwg.org/multipage/embedded-content.html#allowed-to-use

Looking at Gecko's implementation, we do have allowfullscreen that more or less follows the spec's definition (including walking up the browsing context chain, fwiw). We don't have allowusermedia.

But generally speaking, this algorithm as written means that whether the thing is allowed or not can change during the lifetime of the document, due to attribute changes on arbitrary ancestor <iframe> elements. It behaves differently from the feature policy proposals, which snapshot the parent information at document creation time...

It's possible that for allowfullscreen compat constraints mean the check has to be dynamic (though I doubt it), but for new things we should be following the feature policy approach of snapshotting the value at document creation time.

zcorpan added a commit that referenced this issue Dec 9, 2016

zcorpan added a commit that referenced this issue Dec 16, 2016

Snapshot allowfullscreen/allowusermedia/allowpaymentrequest
According to #2184 (comment)
the page that was previously broken by allowfullscreen not being
live has now changed, so it may be possible to move back to the
snapshot model used by <iframe sandbox> and Feature Policy.

Fixes #2143.

This partially reverts 9f6b91c.

@zcorpan zcorpan referenced a pull request that will close this issue Dec 16, 2016

Open

Snapshot allowfullscreen #2187

2 of 4 tasks complete

zcorpan added a commit that referenced this issue Dec 20, 2016

Snapshot allowfullscreen/allowusermedia/allowpaymentrequest
According to #2184 (comment)
the page that was previously broken by allowfullscreen not being
live has now changed, so it may be possible to move back to the
snapshot model used by <iframe sandbox> and Feature Policy.

Fixes #2143.

This partially reverts 9f6b91c.

zcorpan added a commit that referenced this issue Dec 20, 2016

Snapshot the allowpaymentrequest attribute
New allow* attributes should use the snapshot model used by <iframe sandbox>
and Feature Policy. The allowfullscreen and allowusermedia attributes are
left with their current live behavior in this change, because it is not yet
clear if it is Web-compatible to change them (see #2187).

Part of #2143.

annevk added a commit that referenced this issue Jan 14, 2017

Snapshot allowpaymentrequest and allowusermedia attributes
New allow* attributes should use the snapshot model used by <iframe sandbox> and Feature Policy. The allowfullscreen attributes is left with its current live behavior in this change, because it is not yet clear if it is web-compatible to change it (see #2187).

Test: web-platform-tests/wpt#4369.

Part of #2143.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment