Thanks Dominic for that confirmation and your help reviewing. And thank you to Robbie for the impressive improvement to the API surface and the specification!
This looks like a pretty good, webby API, with a nice detailed specification, which I'm happy to approve. LGTM1. Please make sure to update ChromeStatus with the new shipping milestone so that this makes its way into the right channels. On Tue, Jul 15, 2025 at 8:30 AM Dominic Farolino <d...@chromium.org> wrote: > As one of this feature's spec mentors, I'd like to offer a spec maturity > statement > <https://www.chromium.org/blink/spec-mentors/#reviewing-the-specification>. > Since this feature was last discussed, Robbie and the team have made the > changes that API OWNERs and spec reviewers, including myself, have > requested. This addressed concerns about non-webby/legacy Chrome Apps APIs > creeping into the *Web Request API* surface, as well as concerns about > proper event handling integration with the *Context Menus API*. These > changes have been discussed and designed in Controlled Frame API Changes > <https://docs.google.com/document/d/1ixlpnalIk6WhSlZET7_tyRsr3Y1ykiKbxIXR0l_YnkE/edit?tab=t.z85t9gvxifrc#heading=h.obq4y7ssx2wq> > & Controlled Frame WebRequest API > <https://docs.google.com/document/d/1ixlpnalIk6WhSlZET7_tyRsr3Y1ykiKbxIXR0l_YnkE/edit?tab=t.0#heading=h.h1ozrw86mlsa> > (Google-internal, > sorry), and led to pull requests ( > https://github.com/WICG/controlled-frame/pull/138#pullrequestreview-2976534728, > https://github.com/WICG/controlled-frame/pull/144, > https://github.com/WICG/controlled-frame/pull/143, etc.) that myself or > other mentors have approved. > > Additionally, tons of quality and rigor improvements have been made (ex > <https://github.com/WICG/controlled-frame/pull/140>, ex > <https://github.com/WICG/controlled-frame/pull/136>, ex > <https://github.com/WICG/controlled-frame/pull/132>, ex > <https://github.com/WICG/controlled-frame/pull/121>, ex > <https://github.com/WICG/controlled-frame/pull/117>), so huge thanks to > Robbie for this! The spec is in much better shape, and we're finally ready > to circle back here for a round of reviews! > > On Mon, Apr 14, 2025 at 2:26 PM Robbie McElrath <rmcelr...@chromium.org> > wrote: > >> We're now targeting M138 to give us more time to improve the spec. >> >> There hasn't been any spec progress in the last 2 weeks due to some >> unfortunately timed vacations, but I'll be picking that up again starting >> today and responding to feedback from Reilly and Dominic. >> >> On Monday, April 14, 2025 at 11:14:08 AM UTC-7 Alex Russell wrote: >> >>> Any updates here? >>> >>> On Tuesday, March 18, 2025 at 7:34:04 PM UTC-7 Domenic Denicola wrote: >>> >>>> On Tuesday, March 18, 2025 at 8:39:21 AM UTC+9 Robbie McElrath wrote: >>>> >>>> Contact emails >>>> >>>> rmcelr...@chromium.org, ze...@chromium.org >>>> >>>> Explainer >>>> >>>> https://github.com/WICG/controlled-frame/blob/main/README.md >>>> >>>> Specification >>>> >>>> https://wicg.github.io/controlled-frame >>>> >>>> >>>> This is a large specification effort, so thank you for working on it! >>>> >>>> Unfortunately, it seems pretty incomplete right now. E.g. stuff like >>>> https://wicg.github.io/controlled-frame/#dom-htmlcontrolledframeelement-executescript >>>> step 7 or >>>> https://wicg.github.io/controlled-frame/#dom-htmlcontrolledframeelement-insertcss >>>> steps 6-8 are not really specification text, just explainer text in numeric >>>> list format. Similarly >>>> https://wicg.github.io/controlled-frame/#traverse-an-embedded-navigables-history >>>> has a pretty bad TODO. And stuff like >>>> https://wicg.github.io/controlled-frame/#validate-embedded-content >>>> also makes it seem like the specification is not ready. >>>> >>>> To me it doesn't seem like this specification is at the level we >>>> require >>>> <https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines/#specifications>, >>>> i.e. enough to allow interoperable implementation between multiple engines. >>>> >>>> Could you keep working on writing a complete specification, and come >>>> back to us for shipping approval when such a spec is ready? >>>> >>>> I'm also concerned about the section at >>>> https://wicg.github.io/controlled-frame/#api-web-request , which >>>> basically seems to be saying that the proposal authors aren't working to >>>> create a web platform standard here, but instead ship a Chrome Apps API to >>>> the web. I don't know if that's an appropriate thing for us to approve >>>> through the Blink process. Even beyond the issue of creating a rigorous >>>> specification, that decision might need more discussion. >>>> >>>> >>>> >>>> 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 WebView 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 >>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EControlledFrame%22> >>>> >>>> TAG review >>>> >>>> https://github.com/w3ctag/design-reviews/issues/1067 >>>> >>>> TAG review status >>>> >>>> Pending >>>> >>>> Risks >>>> Interoperability and Compatibility >>>> >>>> This is a new API available only within IWAs. As a new API, it is >>>> subject to the risk that other browsers may not implement it. However, >>>> other browsers must also implement IWAs, and for now we are advancing this >>>> to assist our dev partners that are migrating from Chrome Apps. >>>> >>>> The API allows embedding third-party (non-IWA) content. The content >>>> will be loaded within dedicated storage partitions managed by the embedding >>>> application and won't have access to the same site's content as if it was >>>> loaded in a tab. >>>> >>>> >>>> Gecko: No signal >>>> >>>> WebKit: No signal >>>> >>>> Web developers: The WebView API that Controlled Frame is based on has >>>> been used by developers for 15+ years for the use cases outlined in the >>>> explainer. Feedback for Controlled Frame specifically has been requested. >>>> >>>> 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 based on the Chrome Apps WebView API, which >>>> has had the benefit of years of developer partner experience and feedback. >>>> We included some adjustments to the API to ensure it fits into web >>>> technologies like permissions and permissions policy, incorporated >>>> developer partner feedback, and changed or removed some API elements based >>>> on need. >>>> >>>> Activation >>>> >>>> Developers must build an IWA to use the Controlled Frame API. The IWA >>>> they build must then be deployed, currently using managed distribution via >>>> enterprise policy. These hurdles present significant activation risk since >>>> each of these are new technologies and require interaction with multiple >>>> systems. >>>> >>>> Once the IWA is built, using the Controlled Frame element may require >>>> some direct engagement since the methods used to interact with embedded >>>> content are complicated. We recommend additional developer documentation >>>> and outreach directly with development partners. >>>> >>>> >>>> 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 "controlled-frame" 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 >>>> >>>> This API is not available on Android, and has no impact on Android >>>> WebView. >>>> >>>> >>>> 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. >>>> >>>> DevTools is available within the embedded content. >>>> >>>> >>>> Will this feature be supported on all six Blink platforms (Windows, >>>> Mac, Linux, ChromeOS, Android, and Android WebView)? >>>> >>>> No. The Controlled Frame API is not currently 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.) Initially >>>> the API environment is exposed only on ChromeOS >>>> >>>> >>>> Is this feature fully tested by web-platform-tests >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>> ? >>>> >>>> No. WPT does not support PWA/IWA test environments. Once that support >>>> is available, we can investigate adding IWA-focused WPT tests. >>>> >>>> Until then, we have built a pseudo-WPT test environment so we can write >>>> WPT-like tests that work in an IWA context. These are available for review >>>> in the Chromium code repository: >>>> >>>> //chrome/test/data/controlled_frame: >>>> >>>> https://source.chromium.org/chromium/chromium/src/+/main: >>>> chrome/test/data/controlled_frame/ >>>> >>>> //chrome/browser/controlled_frame/controlled_frame_wpt_browsertest.cc: >>>> >>>> https://source.chromium.org/chromium/chromium/src/+/main: >>>> chrome/browser/controlled_frame/controlled_frame_wpt_ >>>> browsertest.cc?q=add_content_scripts&ss=chromium%2Fchromium%2Fsrc >>>> >>>> >>>> DevTrial instructions >>>> >>>> https://github.com/WICG/controlled-frame/tree/main/test_app >>>> >>>> Flag name on about://flags >>>> >>>> ControlledFrame >>>> >>>> Finch feature name >>>> >>>> None >>>> >>>> Non-finch justification >>>> >>>> None >>>> >>>> Requires code in //chrome? >>>> >>>> True >>>> >>>> Tracking bug >>>> >>>> https://crbug.com/40191772 >>>> >>>> Launch bug >>>> >>>> https://launch.corp.google.com/launch/4283394 >>>> >>>> Measurement >>>> >>>> https://chromestatus.com/metrics/feature/timeline/popularity/5205 >>>> >>>> Sample links >>>> >>>> https://github.com/WICG/controlled-frame/tree/main/test_app >>>> >>>> Estimated milestones >>>> >>>> Shipping on desktop >>>> >>>> 136 >>>> >>>> DevTrial on desktop >>>> >>>> 114 >>>> >>>> >>>> Anticipated spec changes >>>> >>>> We’re currently working on expanding many sections of the spec. >>>> >>>> >>>> Link to entry on the Chrome Platform Status >>>> >>>> https://chromestatus.com/feature/5199572022853632?gate=5134483605422080 >>>> >>>> Links to previous Intent discussions >>>> >>>> Intent to Prototype: https://groups.google.com/a/ >>>> chromium.org/d/msgid/blink-dev/CAKcCwFPo79ELzrS5qDcbXNM9K71c1 >>>> a964uqWpMxK0AZNzOXa1w%40mail.gmail.com >>>> >>>> >>>> This intent message was generated by Chrome Platform Status >>>> <https://chromestatus.com/>. >>>> >>>> -- >> 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+unsubscr...@chromium.org. >> To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/34efd23d-c12b-433d-9994-b4b71e891472n%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/34efd23d-c12b-433d-9994-b4b71e891472n%40chromium.org?utm_medium=email&utm_source=footer> >> . >> > -- 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+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9E7vCdxt2dS-syeAF4pvSMabAu9HqU_s_sj%2B1%3DevyL1w%40mail.gmail.com.
