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/CADAcp093eF6ZTSPdVAHAm9bvTLwmL%3DFfVhK%2BTtMp_HY%2B8BgB8w%40mail.gmail.com.
