Another quick update (already updated in the chromestatusentry): We landed the required code in M156. The fenced frame element and window.fence are now stubs starting in M156. We will start the experiment to remove the stubs in M157. Thanks!
On Fri, Aug 28, 2026 at 9:21 AM Shivani Sharma <[email protected]> wrote: > Thanks all! > > To update: The timeline for this needed to be moved forward by a > milestone, and I've updated it in the chromestatusentry > <https://chromestatus.com/feature/6366274495053824>. > > On Mon, Aug 24, 2026 at 2:49 PM Alex Russell <[email protected]> > wrote: > >> LGTM3. >> >> On Friday, August 21, 2026 at 8:31:05 AM UTC-7 Mike Taylor wrote: >> >>> LGTM2 >>> On 8/19/26 12:05 p.m., Vladimir Levin wrote: >>> >>> That sounds good, thanks! >>> >>> LGTM1 >>> >>> On Wed, Aug 19, 2026 at 11:33 AM Xiaochen Zhou <[email protected]> >>> wrote: >>> >>>> > 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 >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/600e2576-a252-493e-8723-516a703226dfn%40chromium.org?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> 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/CADsXd2OnoLy5ksEXTd-V-CGH%3D7nErXOr28ispTyOTCkXSDrz2g%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2OnoLy5ksEXTd-V-CGH%3D7nErXOr28ispTyOTCkXSDrz2g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- 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/CADAcp08TXSpNPCjnNzOmrqVosWkKW7_i4LKTcw7%3D3YhtQAyw%3Dw%40mail.gmail.com.
