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>.
