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.
