Hello, As of writing, the official "Privacy Sandbox feature status" article <https://privacysandbox.google.com/overview/status> 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 <https://github.com/WICG/fenced-frame/commit/1133dcaa93be2d934cfa9c704b4e42875107b550> on February 15, 2026. Perhaps, this article could be updated to communicate deprecation?
Thanks, Anton. On Thursday, August 13, 2026 at 8:11:33 PM UTC+3 [email protected] wrote: > 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 > > On Thu, Aug 13, 2026 at 12:42 PM Shivani Sharma <[email protected]> > wrote: > >> Yes, the Fenced Frames use counter >> <https://chromestatus.com/metrics/webfeature/timeline/popularity/284> >> 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 >> <https://issues.chromium.org/545349630>). >> >> Please let me know if this answers the question. >> >> On Wed, Aug 12, 2026 at 11:43 AM Vladimir Levin <[email protected]> >> wrote: >> >>> 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/3054b1a4-1336-4f6a-86c1-417931cc8a2fn%40chromium.org.
