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/CADAcp0-3Rf3yfd_OAQA_jO9oC%2BH%2BfV6he8oXfi9y%3DmDhiwWw8g%40mail.gmail.com.
