*[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/CADAcp09BcLn5RLGPW7X-dtVT2ZZuAdgtG1BAMy02kSPH7Vr8XA%40mail.gmail.com.
