Intent to Implement and Ship: Snapshot iframe allowfullscreen attribute
Ian Clelland
Contact emails
Spec
HTML spec change discussion at https://github.com/whatwg/html/pull/2187
Summary
Currently the iframe "allowfullscreen" attribute is sampled every time a call is made to Element.requestFullScreen(). For consistency with other platform features like <iframe sandbox>, content-security-policy, and in order to be able to implement Fullscreen as part of Feature Policy, I'd like to change this behavior such that a snapshot of the state of the attribute is taken at the point when the framed document is created.
Motivation
The primary motivation for shipping this is to allow the fullscreen feature to eventually be implemented in terms of Feature Policy, which relies on snapshotting the state of a document at the time of its creation to determine what features should be allowed or not in that document. This change also aligns the behaviour of "allowfullscreen" with that of other features, such as sandboxing and CSP. The allowusermedia and allowpaymentrequest attributes were similarly updated recently to act this way as well. (https://github.com/whatwg/html/pull/2195, https://html.spec.whatwg.org/multipage/embedded-content.html#set-the-allow*-flags)
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Interoperability and Compatibility Risk
Existing websites which rely on the ability to load a document into an iframe, and then subsequently add the allowfullscreen attribute to that frame, will lose the ability for that frame to request fullscreen mode. Sites will have to be written to either reload the framed content in order to change the attribute, or simply include the attribute on the element when it is created.
Firefox attempted to make this change previously, but reverted it because of an instance of breakage (see https://bugzilla.mozilla.org/show_bug.cgi?id=1283526). The page mentioned in that bug has been changed, and does not now pose any interop/compat risk. Since there may still be other pages doing this, I propose to add a use counter (and merge this to M57) to see if there are other sites which change the allowfullscreen flag post document-creation. The behaviour change will be implemented in M58, but if the M57 usage appears significant, then the plans to actually ship in M58 will be re-evaluated. (In that case, we may choose to remove Fullscreen from the initial Feature Policy release, or else ship with a custom "allowed-to-use" algorithm for Fullscreen which tries to respect both the declared feature policy and the live "allowfullscreen" attribute)
Edge:No signals
Firefox:Public support - See comments in https://github.com/whatwg/html/pull/2187
Safari:No signals
Web developers:No signals
Ongoing technical constraints
None.
OWP launch tracking bug
Shipping this is tied to shipping Feature Policy. Launch bug: https://bugs.chromium.org/p/chromium/issues/detail?id=623682
Link to entry on the feature dashboard
None. This is a very small change to the behaviour which doesn't warrant a feature entry of its own. The dashboard entry for Feature Policy, shipping which will actually enable this, is at https://www.chromestatus.com/feature/5694225681219584
Requesting approval to ship?
Yes, subject to risk assessment based on use counters.
Philip Jägenstedt
Mike West
Chris Harrelson
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Dimitri Glazkov
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
kevin....@sendtonews.com
PhistucK
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d68b3fa3-e102-46bc-a053-de4fb7e9ff81%40chromium.org.
Kevin Brogan
I don't understand what problem your load settings on src load feature is trying to fix. If it's a security concern, well then in the case of same origin iframes, as is ours, any security setting can be set to whatever the frame wants by a malicious agent and then a load triggered with any payload at all, even one that is now going to a cross domain origin. In the case of a cross domain iframe, the iframe has no access to begin with, and the only source to change the settings is already outside of the frame and can again set the frame to any setting and load any source.
In both cases, any agent capable of modifying the settings is capable of loading any script in any iframe or even hijacking the parent page or doing anything it wants on the page at all. Forcing a reload hasn't saved anyone and in the end, no security has been gained, only inconvenience for legitimate users. And because we can't be reloading our application and destroying application state everytime one of these settings is changed, we will just force an environment of greatest access. So the publisher ends up losing the ability to specify if they want full screen video or not on their pages if they use our application.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Victor Costan
This will force anyone who wants to selectively enable iframe permissions after the fact, to always enable the permission. You're turning a configurable option into always on if any doubt exists. It will result in iframes having more access, not less. It will break existing implementations. It's a terrible idea all around.