Intent To Prototype: Controlled Frame API for Isolated Web Apps
Chase Phillips
Contact emails
c...@chromium.org, odej...@chromium.org
Explainer
https://github.com/chasephillips/controlled-frame
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
Blink>ControlledFrame (Not yet created. For technical reasons the current implementation is outside of Blink but this refactoring is on our backlog. We want to reflect that the <controlledframe> tag is part of the web rendering engine, i.e. Blink/Content.)
Motivation
IWA use cases such as displaying 3p media sites in virtual desktops with minimal latency, common patterns to deploying kiosk applications, and other scenarios all require the ability to embed and manipulate arbitrary web content.
Initial public proposal
https://github.com/WICG/proposals/issues/88
TAG review
Not yet requested
Risks
Interoperability and Compatibility
Gecko: No signal
WebKit: No signal
Web developers: No signal
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.
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 WebView 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?
Not yet, we plan to add IWA-specific web platform tests as part of our work.
Flag name
IwaControlledFrame
Requires code in //chrome?
True
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1233993
Estimated milestones
No milestones specified
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5199572022853632
This intent message was generated by Chrome Platform Status.