Do you have use counter numbers by any chance? I also have some concern about the plan here. Removing the feature but keeping the idl as stubs for a release sounds like it would break feature detection. Specifically, one could detect that these APIs exist but they do nothing. Can you comment on that? I'd almost want to see a faster removal after a deprecation period, assuming use counters are low enough.
Thanks! Vlad On Tuesday, August 11, 2026 at 4:20:44 PM UTC-4 Shivani Sharma wrote: > *[Adding summary again with formatting since chromestatus formatting > didn't work]* > > *Summary* > Fenced frames are nested frames that embed content onto a page without the > ability to share data between the fenced frame and its embedder. > > window.fence APIs include Fenced frames Ads reporting (FFAR) JS APIs that > were created for privacy-safe ads reporting from FFs created using > Protected Audience and SelectURL and getNestedConfigs() to support PA > component ads. > > This intent is for removing both of these. Fenced frames element removal > will be two step as detailed below. > With the removal (or stub API replacement) of PA and selectURL, FFs can no > longer be navigated and thus it is safe to remove them. > > Fenced frames are only able to be navigated using the urn:uuid in a > FencedFrameConfig[1], which can only be created using the return values > from runAdAuction and selectURL. These APIs are being deprecated and > removed in M152 as per the following Intent threads: Protected Audience[2], > Shared Storage[3]. > > Plan: Given that the fenced frames element can no longer be navigated, we > propose removing the element from the code in the following phases: > 1. M154: Keep the fenced frame element and its associated IDL dependencies > as stubs. This is to ensure no JS call throws, e.g.calling > fenced-frame-element.config.setSharedStorageContext(). > 2. M154: In the same milestone we will also remove the window.fence APIs > completely. Since there is no FF document navigation, these APIs cannot be > invoked anymore, so it will be a no-op. > 3. M155 Canary/Beta: Begin a controlled rollout of the stub FF HTML > element removal via a field trial. Note that removing the element will > resolve it to HTMLUnknownElement. > At this point we are requesting approvals for all of the above steps. > 4. M155 Stable: Assuming there are no regressions or breakage after > reaching 1% stable, we will request additional approval for full removal of > the FF element. > > [1] > https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/fenced_frame/fenced_frame_config.idl > > [2] > https://groups.google.com/a/chromium.org/g/blink-dev/c/k_nubsMb97g/m/awPD4IGLBAAJ > > [3] > https://groups.google.com/a/chromium.org/g/blink-dev/c/uh5Ke6qyegc/m/WFTFnhyJBAAJ > > On Tue, Aug 11, 2026 at 4:17 PM Chromestatus < > [email protected]> wrote: > >> *Contact emails* >> [email protected], [email protected], [email protected] >> >> *Explainer* >> https://github.com/WICG/fenced-frame/blob/master/explainer/README.md >> >> *Specification* >> https://wicg.github.io/fenced-frame >> >> *Summary* >> Fenced frames are nested frames that embed content onto a page without >> the ability to share data between the fenced frame and its embedder. >> window.fence APIs include Fenced frames Ads reporting (FFAR) JS APIs that >> were created for privacy-safe ads reporting from FFs created using >> Protected Audience and SelectURL and getNestedConfigs() to support PA >> component ads. This intent is for removing both of these. Fenced frames >> element removal will be two step as detailed below. With the removal (or >> stub API replacement) of PA and selectURL, FFs can no longer be navigated >> and thus it is safe to remove them. Fenced frames are only able to be >> navigated using the urn:uuid in a FencedFrameConfig[1], which can only be >> created using the return values from runAdAuction and selectURL. These APIs >> are being deprecated and removed in M152 as per the following Intent >> threads: Protected Audience[2], Shared Storage[3]. Plan: Given that the >> fenced frames element can no longer be navigated, we propose removing the >> element from the code in the following phases: 1. M154: Keep the fenced >> frame element and its associated IDL dependencies as stubs. This is to >> ensure no JS call throws, e.g.calling >> fenced-frame-element.config.setSharedStorageContext(). 2. M154: In the same >> milestone we will also remove the window.fence APIs completely. Since there >> is no FF document navigation, these APIs cannot be invoked anymore, so it >> will be a no-op. 3. M155 Canary/Beta: Begin a controlled rollout of the >> stub FF HTML element removal via a field trial. Note that removing the >> element will resolve it to HTMLUnknownElement. At this point we are >> requesting approvals for all of the above steps. 4. M155 Stable: Assuming >> there are no regressions or breakage after reaching 1% stable, we will >> request additional approval for full removal of the FF element. [1] >> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/fenced_frame/fenced_frame_config.idl >> >> [2] >> https://groups.google.com/a/chromium.org/g/blink-dev/c/k_nubsMb97g/m/awPD4IGLBAAJ >> >> [3] >> https://groups.google.com/a/chromium.org/g/blink-dev/c/uh5Ke6qyegc/m/WFTFnhyJBAAJ >> >> >> *Blink component* >> Blink>FencedFrames >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EFencedFrames%22> >> >> *Web Feature ID* >> *No information provided* >> >> *Motivation* >> As described in the summary section, since fenced frames are no longer >> able to be navigated to a document, once PA and selectURL are removed, we >> should also remove FFs API for code health and to remove unused APIs from >> the web platform. >> >> *Initial public proposal* >> *No information provided* >> >> *TAG review* >> *No information provided* >> >> *TAG review status* >> Not applicable >> >> *Goals for experimentation* >> None >> >> *Risks* >> >> >> *Interoperability and Compatibility* >> Since fenced frames were not implemented by other browser vendors, there >> is no interoperability risk. Removing fenced frames is backward compatible >> once PA and selectURL have been removed since FFs can then no longer be >> navigated to a document. But there may be minor inconsistencies b/w FF >> element and HTMLUnknownElement, e.g. their default size so we plan to keep >> FF element as a stub and remove the stub via field trial. >> >> *Gecko*: No signal >> >> *WebKit*: No signal >> >> *Web developers*: No signals >> >> *Other signals*: >> >> *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 information provided* >> >> >> *Debuggability* >> We will add an issue to dev tools when FF is converted to a stub element, >> whenever a FF element is created, that they will be removed shortly. >> >> *Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, ChromeOS, Android, and Android WebView)?* >> Yes >> >> *Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >> Yes >> >> >> *Flag name on about://flags* >> *No information provided* >> >> *Finch feature name* >> *No information provided* >> >> *Non-finch justification* >> *No information provided* >> >> *Rollout plan* >> Will ship enabled for all users >> >> *Requires code in //chrome?* >> False >> >> *Tracking bug* >> https://issues.chromium.org/538634423 >> >> *Estimated milestones* >> Shipping on desktop 154 >> Shipping on Android 154 >> Shipping on WebView 154 >> >> *Anticipated spec changes* >> >> Open questions about a feature may be a source of future web compat or >> interop issues. Please list open issues (e.g. links to known github issues >> in the project for the feature specification) whose resolution may >> introduce web compat/interop risk (e.g., changing to naming or structure of >> the API in a non-backward-compatible way). >> *No information provided* >> >> *Link to entry on the Chrome Platform Status* >> https://chromestatus.com/feature/6366274495053824?gate=5364408546099200 >> >> 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b4e66f8d-9abd-4d04-99a5-fb7f1f873103n%40chromium.org.
