Add `<meta name="responsive-embedded-sizing">` by kojiishi · Pull Request #12444 · whatwg/html

kojiishi · 2026-05-13T08:54:08Z

This adds <meta name="responsive-embedded-sizing"> as an immutable standardized name.

This is used by the CSS responsive embedded sizing flag.

At least two implementers are interested (and none opposed):
- Chromium: https://chromestatus.com/feature/5108373464547328
Tests are written and can be reviewed and commented upon at:
- https://wpt.fyi/results/css/css-sizing/responsive-iframe?label=master&label=experimental&aligned
Implementation bugs are filed:
- Chromium: https://crbug.com/418397278
- Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=2039202
- WebKit: https://bugs.webkit.org/show_bug.cgi?id=314714
Corresponding HTML AAM & ARIA in HTML issues & PRs: N/A
MDN issue is filed: In Chromium Documentation Tracker https://issuetracker.google.com/issues/511947520
The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

/dom.html ( diff )
/infrastructure.html ( diff )
/parsing.html ( diff )
/semantics.html ( diff )

kojiishi · 2026-05-13T09:37:20Z

@chrishtr @bfgeek @annevk @zcorpan

miketaylr · 2026-05-18T01:38:56Z

https://html.spec.whatwg.org/#the-meta-element

If either name, http-equiv, or itemprop is specified, then the content attribute must also be specified. Otherwise, it must be omitted.

But just below:

If a meta element has a name attribute, it sets document metadata.... If a meta element has no content attribute, then the value part of the metadata name-value pair is the empty string.

So meta with name and without content is allowed (but, imho it's a bit confusing for HTML to use must in "this must be specified, otherwise it must not be specified" instead of may?)

kojiishi · 2026-05-25T07:20:07Z

@annevk can you help whether the content attribute is required or not? It looks to me that omitting is allowed from what @miketaylr quoted, but I'm not sure.

@mtrootyy wrote:

If a meta element has no content attribute, then the value part of the metadata name-value pair is the empty string.

The above specifications are for user agents, not for authors. Regardless of how the user agent processes it, author must comply with the following specifications.

If either name, http-equiv, or itemprop is specified, then the content attribute must also be specified.

noamr

(Unofficial as I'm not an approver and we need multi implementer support)
I think this PR does the right thing in a way that's concise and consistent enough.
Editorially I can't say about maintaining the outdated wording style of existing meta tag or moving forward.

noamr · 2026-05-28T19:01:42Z

+    <div algorithm>
+    <p>If a <code>meta</code> element is
+    <span data-x="node is inserted into a document">inserted into the document</span>,
+    the user agent must run the following algorithm:</p>


I think this wording style is outdated but will leave to @annevk whether this needs to be consistent with what's around it or with new style.

OK I looked at other meta elements and you need to check for the name here. Are you ignoring the content? If so it's good to add a note.
Does changing the name attribute work? Is the matching case-sensitive?

Follow based on how other meta elements are speced.

Thanks again, I read others and followed them. Can you check?

noamr · 2026-06-02T10:43:32Z

@kojiishi the tests link points to existing tests in wpt.fyi that are not marked tentative.
Is there good coverage for adding/removing the meta tag dynamically before is seen?

kojiishi · 2026-06-03T05:18:54Z

@noamr

the tests link points to existing tests in wpt.fyi that are not marked tentative.

I removed .tentative because the template of this PR requested me to do so, there's a CSS WG resolution, and the resolution is put in the CSS spec. With this discussion, I will make sure the CSS spec is updated. Was that too early?

Is there good coverage for adding/removing the meta tag dynamically before is seen?

Yes, I think so, though they're based on the previous understanding of the "immutable" in the CSS WG. Among the wpt tests:

meta-in-body tests <meta> appearing in <body>.
meta-afterr-head tests <meta> in after-head insertion mode.
dynamic-append tests appending <meta>.
dynamic-remove tests removing <meta>.
dynamic-write tests document.write.
dynamic-name-change tests changing the name attribute.

I'll update/add tests and Blink once this discussion is settled down.

noamr · 2026-06-03T13:00:01Z

+    <div algorithm>
+    <p>If a <code>meta</code> element is
+    <span data-x="node is inserted into a document">inserted into the document</span>,
+    the user agent must run the following algorithm:</p>


OK I looked at other meta elements and you need to check for the name here. Are you ignoring the content? If so it's good to add a note.
Does changing the name attribute work? Is the matching case-sensitive?

Follow based on how other meta elements are speced.

noamr · 2026-06-11T09:41:38Z

WHATNOT notes/minutes:

Responsive Iframe Meta Tag Proposal: Noam Rosenthal introduced a proposal (PR 12444) to add a meta tag for responsive embedded sizing, which serves as an opt-in for parents to resize iframes. Luke questioned if domain-specific opt-ins are necessary, but Simon Pieters noted that CSP frame ancestors already provide existing protections. The group discussed whether the meta tag provides sufficient control over cross-origin information access, with Noam Rosenthal comparing the functionality to an explicit post-message opt-in.

Responsive Iframe Data Leakage Concerns: The group discussed potential privacy risks, specifically whether responsive iframes could allow an origin to infer information about a user (e.g., whether they are logged into a site) based on size changes. Emilio Cobos Álvarez noted that the CSS working group previously discussed these risks and deemed them manageable if the parent page manages the sizing. Simon Pieters raised concerns regarding how to handle navigations and potential data leakage between pages.

Responsive Iframe Implementation and Documentation: Luke suggested that browsers should provide console warnings if an iframe opts into this feature without appropriate frame ancestor restrictions. Noam Rosenthal committed to updating the security explainer for the PR and consulting with Koji to ensure privacy concerns are addressed. Philip Jägenstedt clarified that fence frames, while still present in Chromium code, are not currently being actively developed.

kojiishi · 2026-07-13T05:43:34Z

I got another feedback from our security folks to add allowed-origin attribute. The value syntax is similar to frame-ancestors, but also allows wildcard. Examples:

<meta name="responsive-embedded-sizing" allowed-origins="https://example.org/ https://example2.org/">
<meta name="responsive-embedded-sizing" allowed-origins="*">

/cc @emilio @smfr

This patch support the `allowed-origins` attribute of the `<meta>` element for responsively-sized iframes. The addition of this attribute is discussed with the security team, and is currently being discussed at WHATWG[1]. This attribute has the same syntax as CSP `frame-ancestors`, and that it reuses the underlying logic. It restricts the effect of `responsive-embedded-sizing` meta tag by the origin of the container. All the changes are under an experimental runtime flag. [1]: whatwg/html#12444 (comment) Bug: 418397278 Change-Id: I2af4c4d4e80e1a3efb8b52ad512f1493157d01b8

This patch support the `allowed-origins` attribute of the `<meta>` element for responsively-sized iframes. The addition of this attribute is discussed with the security team, and is currently being discussed at WHATWG[1]. This attribute has the same syntax as CSP `frame-ancestors`, and that it reuses the underlying logic. It restricts the effect of `responsive-embedded-sizing` meta tag by the origin of the container. All the changes are under an experimental runtime flag. [1]: whatwg/html#12444 (comment) Bug: 418397278 Change-Id: I2af4c4d4e80e1a3efb8b52ad512f1493157d01b8 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8084061 Reviewed-by: Kent Tamura <tkent@chromium.org> Commit-Queue: Koji Ishii <kojii@chromium.org> Auto-Submit: Koji Ishii <kojii@chromium.org> Cr-Commit-Position: refs/heads/main@{#1663715}

noamr · 2026-07-28T19:40:00Z

+       data-x="attr-meta-allowed-origins">allowed-origins</code> attribute,
+       or that attribute's value is not an <span>ancestor-source-list</span>,
+       or that attribute's value does not allow the <span
+       data-x="dom-hyperlink-origin">origin</span> of the <span
+       data-x="doc-container-document">container document</span>
+       by the <span>ancestor-source-list</span> syntax,</p></li>
+      </ul>


Indentation here seems wrong

Fixed the first <p> to be in the next line of <li>. Others look the same as other places, is this what you meant?

zcorpan · 2026-08-03T15:46:31Z

allowed-origins="*"

New attributes shouldn't have dashes. Also maybe the name could be simplified to alloworigins?

kojiishi · 2026-08-03T18:54:33Z

allowed-origins="*"

New attributes shouldn't have dashes. Also maybe the name could be simplified to alloworigins?

Thank you for catching this, @zcorpan. Fixed.

This patch renames the attribute as per the WHATWG feedback[1]. [1]: whatwg/html#12444 (comment) Bug: 418397278 Change-Id: I185e7e7de5411bbfe5d1a6a1c972e05dba49101d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8173946 Auto-Submit: Koji Ishii <kojii@chromium.org> Commit-Queue: Kent Tamura <tkent@chromium.org> Reviewed-by: Kent Tamura <tkent@chromium.org> Cr-Commit-Position: refs/heads/main@{#1673080}

zcorpan · 2026-08-04T08:45:33Z

Actually, maybe the content attribute should be used instead of a new alloworigins attribute. Has this been considered?

noamr · 2026-08-04T08:59:42Z

Actually, maybe the content attribute should be used instead of a new alloworigins attribute. Has this been considered?

Yea that's probably better, like <meta name=viewport content="width=device-width">
we can have <meta name="responsive-embedded-sizing" content="alloworigins=*"> It allows us to extend in the future without adding new attributes to meta`.

This shouldn't change anything security-wise.

Are you ok with this @kojiishi ?

zcorpan · 2026-08-04T08:48:23Z

+       or that attribute's value does not allow the <span
+       data-x="concept-document-origin">origin</span> of <var>element</var>'s <code>node
+       document</code>'s <span data-x="doc-container-document">container document</span>
+       by the <span>ancestor-source-list</span> syntax,</p></li>


"allow ... by the ancestor-source-list syntax" should be changed to instead reference a defined matching algorithm. Maybe a new algorithm similar to https://w3c.github.io/webappsec-csp/#match-url-to-source-list but that takes two origins as input.

Thanks, done, using the algorithm. I didn't understand the last part "but that takes two origins as input", but can you see if the new text resolves your feedback?

zcorpan · 2026-08-04T09:22:30Z

+    document">inserted into the document</span>, or has its <code
+    data-x="attr-meta-name">name</code> or
+    <code data-x="attr-meta-alloworigins">alloworigins</code> attributes changed,
+    user agents must run the following algorithm:</p>


The matching of the parent origin allows obtaining if the parent origin is a specific origin, even if the parent attempted to hide its origin by using the referrerpolicy attribute (which hides the origin in location.ancestorOrigins, see #11560 ).

Thanks for pointing this out. I read relevant text, and it looks to me that the origin is hidden in the Ancestor origins algorithm, but not the origin. Did I miss anything?

zcorpan · 2026-08-04T09:50:11Z

+       <li><p><span>The body element</span> of <var>element</var>'s <code>node document</code> is
+       not null; or</p></li>


This claim in CSS does not hold with the current text in this PR:

Once set to either true or false, the flag will not change its value again for the lifetime of the Document.

In particular, the spec doesn't prevent rerunning these steps after the body element has been parsed, as script could remove the body element, then insert a meta element, then insert the body again.

If the intent is to freeze the policy when a meta element is found or when the body element is parsed, the value should be tri-state (undeclared, false, true), and only change once from undeclared to false or true, and the parser should set the value to false (if still undeclared) when inserting a body or frameset element. (Should this also happen in the XML parser case?)

The CSS spec should also be updated to let HTML cover this aspect, so that there aren't two conflicting definitions.

You're right that currently this PR diverges from CSS. Our intention is to update the CSS spec once it is in consensus here. Ideally I think changing CSS to a link to HTML is the best way, but if it takes time to land this PR, we can add a copy there. /cc @tabatkins

This change is for a review comment on May 28:

I think you can use "body is null" like in https://html.spec.whatwg.org/multipage/dom.html#allows-adding-render-blocking-elements

I like using the precedence, but I'm also fine to define more strict immutable flag as you suggested.

My thought was that aligning with render-blocking makes sense here, as the main essence of making this "immutable" is to not let people modify it while anything renderable exists.

One thing to take into account though is that CSS can make the <head> visible... So perhaps making this immutable is safer. Something like:

unset/true/false

If found, set to true

when the body is seen, if unset, set to false

Thank you for you two reaching a consensus. Updated.

I'm not sure what is the best place to set it to false, I did it in "Other parsing state flags" but your advice is greatly appreciated in advance.

For render-blocking, is it possible to get back to a render-blocking state after the first render? If so maybe that should also be made stricter.

I think there are two approaches for "body is seen":

Define HTML element insertion steps for body and frameset to set the flag to false if unset and the parent is the root html element. (Not sure if HTML element moving steps are needed.)

This works for HTML parser case, XML parser case, and inserting elements with script case.

Set the flag from the HTML parser whenever it would insert a body or frameset element.

This only works for the HTML parser case. The XML parser case needs to be defined separately (see https://html.spec.whatwg.org/#parsing-xhtml-documents ). Scripting case not covered.

I suspect the first option is simpler.

From discussion in WHATNOT @noamr brought up another option:

set the flag to false in the reveal steps.

zcorpan · 2026-08-04T10:41:49Z

+     <li><p>Set <var>element</var>'s <code>node document</code>'s
+     <span data-x="concept-document-responsive-embedded-sizing">responsive embedded sizing</span>
+     to true.</p></li>
+    </ol>


https://drafts.csswg.org/css-sizing-4/#iframe-frame-sizing says

Navigating the iframe’s document causes it to forget its locked embedded ICB size.

This should be formalized in HTML when and how this happens. In particular, if the old document's frame size is kept while the new document is loading, information can leak between origins. (The alloworigins list is a contract between embeddee and embedder, not between embeddee and a new document being navigated to.) The size must be reset before the new document has a chance to make detectable decisions based on the viewport size (for example loading an image from <picture><source media=...> or srcset/sizes in the preload scanner). (Or the new document has to act as if this has happened.)

@tabatkins Can you help this feedback?

You're right about information can leak if the locked embedded ICB size is not reset, and this is to prevent that. The size is kept in CSS, I'm not sure how to define them in HTML.

zcorpan · 2026-08-04T10:52:04Z

Actually, maybe the content attribute should be used instead of a new alloworigins attribute. Has this been considered?

Yea that's probably better, like <meta name=viewport content="width=device-width"> we can have <meta name="responsive-embedded-sizing" content="alloworigins=*"> It allows us to extend in the future without adding new attributes to meta`.

Or even content="*". If more metadata is needed in the future, that can be added in new attributes.

This patch support the `allowed-origins` attribute of the `<meta>` element for responsively-sized iframes. The addition of this attribute is discussed with the security team, and is currently being discussed at WHATWG[1]. This attribute has the same syntax as CSP `frame-ancestors`, and that it reuses the underlying logic. It restricts the effect of `responsive-embedded-sizing` meta tag by the origin of the container. All the changes are under an experimental runtime flag. [1]: whatwg/html#12444 (comment) Bug: 418397278 Change-Id: I2af4c4d4e80e1a3efb8b52ad512f1493157d01b8 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8084061 Reviewed-by: Kent Tamura <tkent@chromium.org> Commit-Queue: Koji Ishii <kojii@chromium.org> Auto-Submit: Koji Ishii <kojii@chromium.org> Cr-Commit-Position: refs/heads/main@{#1663715} Co-authored-by: Koji Ishii <kojii@chromium.org>

kojiishi · 2026-08-05T19:13:52Z

Actually, maybe the content attribute should be used instead of a new alloworigins attribute. Has this been considered?

Yea that's probably better, like <meta name=viewport content="width=device-width"> we can have <meta name="responsive-embedded-sizing" content="alloworigins=*"> It allows us to extend in the future without adding new attributes to meta`.

Or even content="*". If more metadata is needed in the future, that can be added in new attributes.

Sounds good to me, and I like the simpler one. Updated to content="*".

This adds `<meta name="responsive-embedded-sizing">` as an immutable standardized name. This is used by the CSS [responsive embedded sizing flag]. [responsive embedded sizing flag]: https://drafts.csswg.org/css-sizing-4/#document-responsive-embedded-sizing-flag

For specifying the allowed origins, instead of adding a new attribute, as per the feedback[1]. [1]: whatwg/html#12444 (comment) Bug: 418397278 Change-Id: I78705424dd480737e1204f54e880a86071525c6d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8211759 Auto-Submit: Koji Ishii <kojii@chromium.org> Reviewed-by: Kent Tamura <tkent@chromium.org> Commit-Queue: Kent Tamura <tkent@chromium.org> Cr-Commit-Position: refs/heads/main@{#1674776}

This patch renames the attribute as per the WHATWG feedback[1]. [1]: whatwg/html#12444 (comment) Bug: 418397278 Change-Id: I185e7e7de5411bbfe5d1a6a1c972e05dba49101d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8173946 Auto-Submit: Koji Ishii <kojii@chromium.org> Commit-Queue: Kent Tamura <tkent@chromium.org> Reviewed-by: Kent Tamura <tkent@chromium.org> Cr-Commit-Position: refs/heads/main@{#1673080} Co-authored-by: Koji Ishii <kojii@chromium.org>

…bute, a=testonly Automatic update from web-platform-tests [iframe] Support `allowed-origins` attribute (#61344) This patch support the `allowed-origins` attribute of the `<meta>` element for responsively-sized iframes. The addition of this attribute is discussed with the security team, and is currently being discussed at WHATWG[1]. This attribute has the same syntax as CSP `frame-ancestors`, and that it reuses the underlying logic. It restricts the effect of `responsive-embedded-sizing` meta tag by the origin of the container. All the changes are under an experimental runtime flag. [1]: whatwg/html#12444 (comment) Bug: 418397278 Change-Id: I2af4c4d4e80e1a3efb8b52ad512f1493157d01b8 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8084061 Reviewed-by: Kent Tamura <tkent@chromium.org> Commit-Queue: Koji Ishii <kojii@chromium.org> Auto-Submit: Koji Ishii <kojii@chromium.org> Cr-Commit-Position: refs/heads/main@{#1663715} Co-authored-by: Koji Ishii <kojii@chromium.org> -- wpt-commits: f1401e8ac6cac0cbe6f3008fbbc0edafd73b9d34 wpt-pr: 61344

kojiishi force-pushed the responsive-embedded-sizing branch from 4f63023 to 5d63e86 Compare May 13, 2026 09:09

kojiishi mentioned this pull request May 13, 2026

Responsively-sized iframes mozilla/standards-positions#1394

Open

This comment was marked as resolved.

Sign in to view

annevk reviewed May 18, 2026

View reviewed changes

Comment thread source Outdated

kojiishi force-pushed the responsive-embedded-sizing branch from 5d63e86 to ad98ae3 Compare May 28, 2026 08:51

noamr reviewed May 28, 2026

View reviewed changes

Comment thread source Outdated

Comment thread source Outdated

Comment thread source Outdated

kojiishi force-pushed the responsive-embedded-sizing branch from ad98ae3 to 49c5445 Compare May 28, 2026 16:22

noamr reviewed May 28, 2026

View reviewed changes

Comment thread source Outdated

kojiishi force-pushed the responsive-embedded-sizing branch 2 times, most recently from fe4fc74 to 615fb1c Compare May 28, 2026 17:34

noamr approved these changes May 28, 2026

View reviewed changes

noamr reviewed Jun 3, 2026

View reviewed changes

noamr self-requested a review June 3, 2026 13:00

kojiishi force-pushed the responsive-embedded-sizing branch from 615fb1c to 6404dc1 Compare June 5, 2026 17:59

mtrootyy reviewed Jun 5, 2026

View reviewed changes

Comment thread source

annevk mentioned this pull request Jul 3, 2026

[css-sizing] Auto-resize iframes based on content w3c/csswg-drafts#1771

Open

kojiishi force-pushed the responsive-embedded-sizing branch from 6404dc1 to 43cbcf8 Compare July 13, 2026 06:21

noamr reviewed Jul 13, 2026

View reviewed changes

Comment thread source Outdated

kojiishi force-pushed the responsive-embedded-sizing branch from 43cbcf8 to 89778a0 Compare July 13, 2026 10:29

chromium-wpt-export-bot mentioned this pull request Jul 16, 2026

[iframe] Support allowed-origins attribute web-platform-tests/wpt#61344

Merged

kojiishi force-pushed the responsive-embedded-sizing branch from 37fa621 to 7af5c6e Compare July 28, 2026 13:53

noamr reviewed Jul 28, 2026

View reviewed changes

Comment thread source Outdated

kojiishi force-pushed the responsive-embedded-sizing branch from 7af5c6e to 02d8b1e Compare July 28, 2026 19:21

noamr reviewed Jul 28, 2026

View reviewed changes

emilio reviewed Aug 3, 2026

View reviewed changes

Comment thread source Outdated

kojiishi force-pushed the responsive-embedded-sizing branch from 02d8b1e to 2a43d88 Compare August 3, 2026 18:53

kojiishi force-pushed the responsive-embedded-sizing branch from 2a43d88 to 6f46cac Compare August 3, 2026 18:59

kojiishi mentioned this pull request Aug 4, 2026

[css-sizing-4] Update Responsively-sized iframes for HTML PR w3c/csswg-drafts#14261

Draft

zcorpan requested changes Aug 4, 2026

View reviewed changes

chromium-wpt-export-bot mentioned this pull request Aug 4, 2026

[iframe] Rename allowed-origins to alloworigins web-platform-tests/wpt#61725

Merged

kojiishi force-pushed the responsive-embedded-sizing branch from 6f46cac to 7afead6 Compare August 5, 2026 19:12

kojiishi force-pushed the responsive-embedded-sizing branch 3 times, most recently from d5e89ad to a9ecb3a Compare August 6, 2026 07:09

kojiishi force-pushed the responsive-embedded-sizing branch from a9ecb3a to e805016 Compare August 6, 2026 07:41

noamr removed the agenda+ To be discussed at a triage meeting label Aug 6, 2026

noamr self-requested a review August 6, 2026 12:47

chromium-wpt-export-bot mentioned this pull request Aug 6, 2026

[iframe] Use the content attribute web-platform-tests/wpt#61797

Open

		<li><p><span>The body element</span> of <var>element</var>'s <code>node document</code> is
		not null; or</p></li>

Uh oh!

Conversation

kojiishi commented May 13, 2026 • edited by pr-preview Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kojiishi commented May 13, 2026

Uh oh!

This comment was marked as resolved.

miketaylr commented May 18, 2026

Uh oh!

This comment was marked as resolved.

Uh oh!

kojiishi commented May 25, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

noamr left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

noamr commented Jun 2, 2026

Uh oh!

kojiishi commented Jun 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

noamr commented Jun 11, 2026

Uh oh!

kojiishi commented Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

noamr Jul 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

zcorpan commented Aug 3, 2026

Uh oh!

kojiishi commented Aug 3, 2026

Uh oh!

zcorpan commented Aug 4, 2026

Uh oh!

noamr commented Aug 4, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kojiishi Aug 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zcorpan Aug 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kojiishi Aug 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

kojiishi commented May 13, 2026 •

edited by pr-preview Bot

Loading

noamr left a comment •

edited

Loading

kojiishi commented Jun 3, 2026 •

edited

Loading

kojiishi commented Jul 13, 2026 •

edited

Loading

noamr Jul 28, 2026 •

edited

Loading

kojiishi Aug 5, 2026 •

edited

Loading

zcorpan Aug 4, 2026 •

edited

Loading

kojiishi Aug 6, 2026 •

edited

Loading

zcorpan Aug 6, 2026 •

edited

Loading