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/f10c7c2e-27cb-4e08-bcf7-d148efff17d4n%40chromium.org.
