> Does M154 also come with a deprecation warning or is this just going be a silent stub?
There will be a DevTools warning on Fenced Frame removal added to M154. It will show whenever a Fenced Frame is created. On Friday, August 14, 2026 at 7:37:46 AM UTC-4 Shivani Sharma wrote: > On Fri, Aug 14, 2026 at 2:34 AM Anton Bershanskyi <[email protected]> > wrote: > >> 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, yes we plan to update the documentation shortly. > >> >> 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/600e2576-a252-493e-8723-516a703226dfn%40chromium.org.
