Ready for Trial: Controlled Frame API (available only to IWAs)
Ajay Rahatekar
Contact emails
c...@chromium.org, odej...@chromium.org
Explainer
https://github.com/chasephillips/controlled-frame/blob/main/EXPLAINER.md
Specification
In Progress.
Summary
Adds a Controlled Frame API available only to Isolated Web Apps (IWAs).
This work will add a new Controlled Frame API which is only available to Isolated Web Apps (IWAs). Like similarly-named APIs on other platforms, Controlled Frame allows embedding all content, even third party content that can't be embedded in <iframe>. Controlled Frame also allows controlling embedded content with a collection of API methods and events.
For more info on Isolated Web Apps, see the IWA explainer: https://github.com/WICG/isolated-web-apps/blob/main/README.md
Blink component
TAG review
Not yet requested
Risks
Interoperability and Compatibility
Gecko: No signal
WebKit: No signal
Web developers: No signals
Other signals: Controlled Frame is very similar to WebView APIs. Work in W3C around WebViews is on-going, documenting their existing and potential uses. We have been participating in discussions and hope to offer insights with our design, implementation, and community feedback. Internal partners have requested embedding APIs that can be used in web apps
Ergonomics
The Controlled Frame API is under development. We will base it initially on the Chrome Apps WebView API. That API has had the benefit of years of developer partner experience and feedback. We also plan to include reasonable adjustments to the API in the first stable version to ensure it fits into web technologies like permissions and permissions policy, incorporating developer partner feedback, and changing or removing some API elements based on need.
Security
Controlled Frame is only available to IWAs, which restricts the API so that it's not accessible to normal web pages and normal web applications. Controlled Frame integrates with Permissions Policy and requires the IWA to include the "controlledframe" policy-controlled feature in the IWA manifest in order for the feature to be enabled. Controlled Frame containers inherit a permissions policy from the embedding frame and policy-controlled features are only available if those features are enabled in the embedding frame. Features that use permissions require the embedder to allow those permissions, and the embedder itself must already have that permission in order to allow the embedded content to use it.
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No, since Controlled Frame is not available to Android.
Goals for experimentation
Partner feedback on initial implementation.
Debuggability
Console messages within a nested browsing context fire an event that the embedder can choose to display (e.g. to the user, via console.log() to show it in DevTools, etc).
Events are generated in the API for certain kinds of actions that occur within an embedded frame's lifetime.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
No. The Controlled Frame API will not be supported on Android. (This work is conceptually similar to Android WebView but is unrelated as this proposal targets building a WebView-related API for IWAs.)
Is this feature fully tested by web-platform-tests?
No
Flag name
IwaControlledFrame
Requires code in //chrome?
True
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1233993
Estimated milestones
M114
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5199572022853632