Intent to Ship: Remove FencedFrame element and window.fence APIs

[Chromestatus]

Contact emails

shiva...@chromium.org, jka...@chromium.org, skman...@google.com

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

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?

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.

[Shivani Sharma]

[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

[Vladimir Levin]

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

[Shivani Sharma]

Yes, the Fenced Frames use counter shows usage on approximately 0.07% of page loads.

Note that this counter tracks the instantiation of the <fencedframe> element rather than successful navigation. Since the default URL mode (via new FencedFrameConfig(url)) has always been disabled by default on Stable, and the navigation APIs (runAdAuction and selectURL) are already stubbed and being removed (a precondition to FF's stubbing and removal), these elements can no longer navigate (internal UMA metrics confirms that).

Regarding the concern about breaking feature detection: Websites cannot rely solely on the existence of window.HTMLFencedFrameElement to assume Fenced Frame navigations will succeed. For example, if a user disables the Privacy Sandbox via Chrome settings, the HTMLFencedFrameElement interface remains defined on the window, but the APIs to obtain a navigation config (runAdAuction, selectURL) return null or reject. Websites already must handle this case gracefully.

Staged removal via stubs and Finch: If we remove the element completely immediately, it will resolve to HTMLUnknownElement. This causes it to lose its default 300x150 sizing, collapsing to 0x0 unless explicitly sized in CSS. Staging this transition—keeping it as a stub in M154 and rolling out the element removal via Finch in M155—allows a gradual transition, rather than risking sudden layout regressions for 100% of Stable users at once.

Also a correction on the original intent mentioning stubbing the `fenced-frame-element.config.setSharedStorageContext()` API but that would not be needed since shared storage removal will remove that (tracking bug).  

Please let me know if this answers the question.

[Vladimir Levin]

This answers the question, thank you.

Does M154 also come with a deprecation warning or is this just going be a silent stub? I'm curious if there is some forcing function for developers to realize that this is going to be removed in M155?

Thanks,

Vlad

[Anton Bershanskyi]

Hello,

As of writing, the official "Privacy Sandbox feature status" article includes a table "Fenced Frames" status as "Continue to support" and then later down lists it as "In general availability in Chrome.". The article includes timestamp "Last updated: October 17, 2025" so it was written before Fenced Frame API specification was archived on GitHub on February 15, 2026. Perhaps, this article could be updated to communicate deprecation?

Thanks,

Anton.

[Shivani Sharma]

On Fri, Aug 14, 2026 at 2:34 AM Anton Bershanskyi <bersh...@gmail.com> wrote:

Hello,

As of writing, the official "Privacy Sandbox feature status" article includes a table "Fenced Frames" status as "Continue to support" and then later down lists it as "In general availability in Chrome.". The article includes timestamp "Last updated: October 17, 2025" so it was written before Fenced Frame API specification was archived on GitHub on February 15, 2026. Perhaps, this article could be updated to communicate deprecation?

Thanks, yes we plan to update the documentation shortly.