-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Snapshot allowfullscreen #2187
Snapshot allowfullscreen #2187
Conversation
I would definitely like to see allowfullscreen eventually defined in terms of Feature Policy, so the more similar we can make it in the interim the better. @clelland @LoonyBean, do you know what the exact timing of when Feature Policy would snapshot its state is? I'd like to add a use counter to see how often this change would prevent fullscreen currently allowed. |
Tests for Tests for |
@foolip - The plan is to have the embedding document's feature policy snapshotted at the point where the nested browsing context of the frame is navigated. (This is roughly the same behaviour as that of the iframe sandbox attribute.) The full policy won't be set at that point; it will need to wait until the HTTP headers for the framed content have been received. The snapshotted policy from the embedder will be combined with the embedded document's headers at the point when the embedded Document is created, I believe. |
@clelland the iframe sandbox attribute is snapshotted, per spec, when the new document in the subframe is created. That's certainly what Firefox does. Is that not what Chrome does? I expected feature policy to work exactly the same way, based on the explainer, which says "Define an inherited policy for feature for origin when document is initialized". |
Thanks, @bzbarsky -- you're right there -- it's part of [Initializing a new Document object], and it looks like Chrome follows the spec. That means we definitely can resolve the policy inherited from the parent at the same time that we construct the policy for the child. |
@clelland, as implemented in Blink, is it indistinguishable in timing from when the sandbox attribute is read, even if not close by in the code? |
@clelland @bzbarsky I written a test for the timing aspect in web-platform-tests/wpt@c050814 |
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.
7cc791c
to
f33d421
Compare
I made a new pull request to only change |
I think we should do this, but there is a decent chance that it won't work out for the allowfullscreen case. However, as soon as there's one engine who wants to attempt the change, I think we should merge this. @upsuper, are you going to do it for Gecko? In Chromium, I wonder if it might be best to combine with @clelland's plans for defining |
This PR is currently lagging behind #2195 so see that PR for now what the behavior should be. When that one is merged I will rebase and fixup this one for allowfullscreen/allowusermedia. |
@foolip, I'm not sure about Gecko's plan of Feature Policy. @bzbarsky may know more about that. I guess it might be better to combine them for us as well. But with the previous experience, I think adding (or blocking) this solely for |
@foolip I run chrome on this device and would like to help test this pull request Would it be best to test it here on Github or should I pop over to the Google Git Chromium repo instead. |
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.
|
[blink-dev] Intent to Implement and Ship: Snapshot iframe allowfullscreen attribute |
We do have implementer interest now, but do we want to leave this open until we see the compat fallout? One downside of this is that any tests can't be done inside of web-platform-tests up-front and we may forget to share them later, but I don't see any way around this and think it's the right trade-off here. |
To avoid flip-flopping the standard (and web-platform-tests) I think we should leave this open until we have a clearer picture of what the web compat situation is like. The time to merge this (or not) will maybe function as a reminder to upstream the tests. WDYT? |
I agree, let's go with that. |
Looks like, at least textually, #3287 doesn't include the same bits as this PR. Is this PR actually obsoleted, and if so should it be closed? |
See #2187 (comment). I think we should close it once we land the other. |
That is the comment I was reacting to, but OK, this isn't accidentally left open, which is what I suspected. |
#3287 got merged, so we can close this. (Please reopen if I got that wrong...) |
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 whatwg#2187). Test: web-platform-tests/wpt#4369. Part of whatwg#2143.
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.
@upsuper said:
So, first, interest to do this at all, then y'all can figure out how to coordinate when to switch.