Introduce DOM post-connection steps #1261

domfarolino · 2024-02-28T16:40:34Z

This PR introduces a node's set of post-connection steps. For any given #concept-node-insert operation, these steps run for each inserted node synchronously after all DOM insertions are complete. This PR is meant to supersede the similar #732.

The goal here is to separate the following:

Script-observable but not-script-executing insertion side effects
- This includes synchronously applying styles to the document, etc...
Script-executing insertion side effects
- This includes creating an iframe's document and synchronously firing its load event

For any given call to #concept-node-insert, the above model allows us to keep all of (1) running synchronously after each node's insertion (as part of its insertion steps), while pushing all script-executing (or DOM tree-modifying or frame tree-modifying etc.) side effects to the new set of post-connection steps, which run synchronously during insertion, but after all nodes finish their insertion.

This essentially makes insertions "atomic" from the perspective of script, since script will not run until a given batch of DOM insertions are complete. This two-stage approach aligns the spec with a model most similar to Blink & Gecko's implementation, and fixes #808. This PR also helps out with whatwg/html#1127 and #575 (per #732 (comment)).

To accomplish, this we audited all insertion side effects on the web platform in https://docs.google.com/document/d/1Fu_pgSBziVIBG4MLjorpfkLTpPD6-XI3dTVrx4CZoqY/edit#heading=h.q06t2gg4vpw, and catalogued whether they have script-observable side-effects, whether they invoke script, whether we have tests for them, and how each implementation handles them. This gave us a list of present "insertion steps" that should move to the "post-connection steps", because they invoke script and therefore prevent insertions from being "atomic". This PR is powerless without counterpart changes to HTML, which will actually use the post-connection steps for all current insertion steps that invoke script or modify the frame tree. The follow-up HTML work is tracked, at the time of writing this:

Use DOM's post-insertion steps for <script> elements html#10188
Meta element and DOM post-insertion steps html#10241
<another incoming PR will be made for iframes>
At least two implementers are interested (and none opposed):
- ✅ Chrome (mostly implements this model; fails at least one "nested script ordering" test)
- ✅ Firefox (mostly implements this model; fails a few tests that rely on iframe load event being fired synchronously, since I guess it fires this event asynchronously..)
- 🟠 Safari: @annevk would you be able to provide a WebKit signal here or should I file a standards position issue?
Tests are written and can be reviewed and commented upon at:
Implementation bugs are filed: N/A given Introduce DOM post-connection steps #1261 (comment).
MDN issue is filed: …
The top of this comment includes a clear commit message to use.

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

Two things need more discussion:

Script child element mutation:
- Use a queue of deferred steps in the node insertion algorithm #732 (review) and Use the new definition of the insertion steps html#4354 (comment) discuss Chromium & WebKit's model of not executing scripts when their children are modified except for insertion.
  - Regarding insertion only: All browsers are aligned on executing a script (that hasn't "already started") when a single child node is inserted. For insertion multiple child nodes atomically, see this WPT which Chrome & Firefox pass, and WebKit barely misses due to the post-connection steps¹. (Related: all browsers are consistent (see this test case) about not executing newly-inserted text nodes in a script that has "already started")
  - Regarding child removal/change: As a follow-up to Use a queue of deferred steps in the node insertion algorithm #732 (review) and Use the new definition of the insertion steps html#4354 (comment), I've investigated this a little more and found that actually all browsers follow the Chromium behavior here. See this WPT (from WPT: Script child removal does not trigger execution web-platform-tests/wpt#45085), where all browsers never trigger the execution of a script when a child node is removed. To accomplish this with the spec, we should probably just add an argument to the child changed steps, but that can be done in a follow-up PR to Use DOM's post-insertion steps for <script> elements html#10188, since it is slightly orthogonal
- The only oddity I can find with scripts in Chromium's model is that we don't follow this rule exactly, which mandates that when a script (that hasn't already started yet) gets a child <script> inserted into it, it must execute after that child script does. Chromium does not do that; the child mutation of the outer script (that inserts the inner <script>) triggers the execution of the outer script in its post-connection steps, and then after, the execution of the inner script during its post-connection steps. WebKit is aligned with Chrome on this and Firefox is the odd one out. Maybe we're OK aligning with Chrome/Firefox in this case?
Dealing with "removal" steps
- In general, removal is distinct from insertion, and I think has no bearing on the decisions we make in this PR and its corresponding HTML one. However, through some offline discussion, we didn't want to commit to this insertion model without having done some investigation into the removal side of things. I've started this in this doc, but see the summary here. Basically there are only two places during Node removal where browsers ever synchronously execute script: (1) pagehide which all browsers do on same-origin iframes, and (2) blur events (only Chrome does this).
- Chrome is committed to experimenting with not firing in either of these scenarios. Along with the deprecation of mutation events, this should mark the end of all synchronous script execution on Node removal

Preview | Diff

The only reason WebKit fails this is because due to the lack of post-connection steps, the script executes after the first text node is appended, so by the time the second text node gets attached, the script is already started ↩

dom.bs

domfarolino · 2024-03-08T03:19:52Z

PTAL @annevk! I'll prepare an HTML PR and commit message for this, as well as file the appropriate browser bugs. But I'd love your thoughts on the meat of this so far, since it should be good to once those particulars are done.

dom.bs

Given the old Chromium change that introduced this behavior: - https://source.chromium.org/chromium/chromium/src/+/604e798ec6ee30f44d57a5c4a44ce3dab3a871ed ... the old discussion in: - whatwg/dom#732 (review) - whatwg/html#4354 (comment) ... and the much newer discussion in: - whatwg/dom#1261 - whatwg/html#10188 This CL upstreams an old test ensuring that removal of a child node from a script node that has not "already started" [1], does not trigger script execution. Only the *insertion* of child nodes (to a non-already-started script node) should trigger that script's execution. [1]: https://html.spec.whatwg.org/C#already-started R=nrosenthal@chromium.org Bug: 40150299 Change-Id: I750ccee0a2be834360c557042e975547c8ddd32c

domfarolino · 2024-03-13T19:05:06Z

Just a quick note for reviewers that have already taken a look: I've just edited the OP to elaborate on the fact that all browsers never execute a script as a result of removing a child node from it. This was previously pointed out in #732 (review) and whatwg/html#4354 (comment) as a maybe-Chromium-only thing — although it appears at the time, at least Chromium & WebKit behaved this way, and as of now, all browsers agree on this. Above, I've elaborated on what follow-up work can be done to DOM/HTML to align the spec with implementations. (Like I said, I don't think it needs to be handled immediately in this PR or in whatwg/html#10188.)

Given the old Chromium change that introduced this behavior: - https://source.chromium.org/chromium/chromium/src/+/604e798ec6ee30f44d57a5c4a44ce3dab3a871ed ... the old discussion in: - whatwg/dom#732 (review) - whatwg/html#4354 (comment) ... and the much newer discussion in: - whatwg/dom#1261 - whatwg/html#10188 This CL upstreams an old test ensuring that removal of a child node from a script node that has not "already started" [1], does not trigger script execution. Only the *insertion* of child nodes (to a non-already-started script node) should trigger that script's execution. [1]: https://html.spec.whatwg.org/C#already-started R=nrosenthal@chromium.org Bug: 40150299 Change-Id: I750ccee0a2be834360c557042e975547c8ddd32c Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5367238 Reviewed-by: Noam Rosenthal <nrosenthal@chromium.org> Commit-Queue: Dominic Farolino <dom@chromium.org> Cr-Commit-Position: refs/heads/main@{#1272330}

domfarolino · 2024-03-14T13:58:44Z

FWIW, even though much of the prior discussion about this and #808 makes it seem like WebKit doesn't implement the post-insertion steps that this PR introduces, the only reason that Blink implements this correctly is because it inherited the code from WebKit!

See https://github.com/WebKit/WebKit/blob/main/Source/WebCore/dom/ContainerNodeAlgorithms.cpp#L54 in WebKit, where we track which elements have post-insertion steps to call later, as well as the and the equivalent code in Blink https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/container_node.cc;l=1095-1096;drc=54b5f6dcc0e51751aec186771b4012ef663b538b.

Also see https://github.com/WebKit/WebKit/blob/main/Source/WebCore/dom/ContainerNode.cpp#L302-L307 in WebKit, where we run each eligible element's post-insertion steps after the children change steps, and the equivalent code in Blink https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/container_node.cc;l=1071-1077;drc=9ab453c8e7d336f430c50488e8638ca802b69d80.

For script execution, WebKit even requests that post-insertion steps are used, I just don't really understand why WebKit fails tests like this then: https://wpt.fyi/results/dom/nodes/insertion-removing-steps/Node-appendChild-script-and-button-from-div.tentative.html?label=experimental&label=master&aligned. Someone like @rniwa probably knows though.

…er execution, a=testonly Automatic update from web-platform-tests WPT: Script child removal does not trigger execution Given the old Chromium change that introduced this behavior: - https://source.chromium.org/chromium/chromium/src/+/604e798ec6ee30f44d57a5c4a44ce3dab3a871ed ... the old discussion in: - whatwg/dom#732 (review) - whatwg/html#4354 (comment) ... and the much newer discussion in: - whatwg/dom#1261 - whatwg/html#10188 This CL upstreams an old test ensuring that removal of a child node from a script node that has not "already started" [1], does not trigger script execution. Only the *insertion* of child nodes (to a non-already-started script node) should trigger that script's execution. [1]: https://html.spec.whatwg.org/C#already-started R=nrosenthal@chromium.org Bug: 40150299 Change-Id: I750ccee0a2be834360c557042e975547c8ddd32c Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5367238 Reviewed-by: Noam Rosenthal <nrosenthal@chromium.org> Commit-Queue: Dominic Farolino <dom@chromium.org> Cr-Commit-Position: refs/heads/main@{#1272330} -- wpt-commits: cc99c62762135f7e193941e32c3f738960c256be wpt-pr: 45085

Given the old Chromium change that introduced this behavior: - https://source.chromium.org/chromium/chromium/src/+/604e798ec6ee30f44d57a5c4a44ce3dab3a871ed ... the old discussion in: - whatwg/dom#732 (review) - whatwg/html#4354 (comment) ... and the much newer discussion in: - whatwg/dom#1261 - whatwg/html#10188 This CL upstreams an old test ensuring that removal of a child node from a script node that has not "already started" [1], does not trigger script execution. Only the *insertion* of child nodes (to a non-already-started script node) should trigger that script's execution. [1]: https://html.spec.whatwg.org/C#already-started R=nrosenthal@chromium.org Bug: 40150299 Change-Id: I750ccee0a2be834360c557042e975547c8ddd32c Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5367238 Reviewed-by: Noam Rosenthal <nrosenthal@chromium.org> Commit-Queue: Dominic Farolino <dom@chromium.org> Cr-Commit-Position: refs/heads/main@{#1272330}

dom.bs

rniwa · 2024-03-26T21:21:27Z

Also see https://github.com/WebKit/WebKit/blob/main/Source/WebCore/dom/ContainerNode.cpp#L302-L307 in WebKit, where we run each eligible element's post-insertion steps after the children change steps, and the equivalent code in Blink https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/container_node.cc;l=1071-1077;drc=9ab453c8e7d336f430c50488e8638ca802b69d80.

For script execution, WebKit even requests that post-insertion steps are used, I just don't really understand why WebKit fails tests like this then: https://wpt.fyi/results/dom/nodes/insertion-removing-steps/Node-appendChild-script-and-button-from-div.tentative.html?label=experimental&label=master&aligned. Someone like @rniwa probably knows though.

It's because in WebKit, updating of element.form also happens in the post insertion steps.

domfarolino · 2024-03-26T21:33:40Z

It's because in WebKit, updating of element.form also happens in the post insertion steps.

Good to know. Do you think WebKit would be willing to change that? It's not a decision that needs to block this PR, since this PR just gives us the primitives available for HTML to do whatever we decide. But so far it seems 2/3 impls agree on that specific case.

rniwa · 2024-03-26T21:35:34Z

It's because in WebKit, updating of element.form also happens in the post insertion steps.

Good to know. Do you think WebKit would be willing to change that? It's not a decision that needs to block this PR, since this PR just gives us the primitives available for HTML to do whatever we decide. But so far it seems 2/3 impls agree on that specific case.

Unlikely. There are some design & performance constraints about this.

domfarolino · 2024-03-27T12:37:28Z

Unlikely. There are some design & performance constraints about this.

I'd appreciate some elaboration on this, just to understand why other browsers seem to be OK not doing this. However, it is a low priority discussion relative to this PR, since this PR doesn't change anything WRT that scenario specifically. But if you'd be willing to review this PR that would be great.

domfarolino · 2024-04-01T20:35:01Z

Gentle ping for reviews (and for a response to #1261 (comment)).

annevk

This looks good to me. I'm not particularly happy about the current hooks as they don't deal with ordering very well. I suppose HTML largely takes care of that, but at some point we should have something better.

dom.bs

annevk · 2024-04-04T15:56:25Z

I don't think we need implementation bugs for this PR given its largely non-normative nature. Can you update the proposed commit message so it's clearer where the corresponding HTML work happens? I found these two so far:

Given that we have a concrete HTML PR I think we can merge this, but I'd like to give folks a bit more time to comment. So let's say I merge this next week Wednesday, barring any other feedback.

annevk · 2024-04-10T15:03:55Z

Let's see if we can briefly discuss this tomorrow. I do see the appeal of Gecko's script runner approach as it avoids the ordering issue. On the other hand, thus far the ordering issue is largely theoretical given the limited number of things we expect will need to be changed.

domfarolino · 2024-04-11T15:12:18Z

Can you update the proposed commit message so it's clearer where the corresponding HTML work happens?

Done. I've updated the first few paragraphs in the OP to include this, and I think those paragraphs would make a good commit message, but let me know if you'd like me to distill it down further.

smaug---- · 2024-04-11T19:54:51Z

dom.bs

+   <var>node</var>, in <a>shadow-including tree order</a>, run the <a>post-insertion steps</a> with
+   <var>inclusiveDescendant</var>.
+  </ol>
+ </li>


Adding the same comment here what I added to #whatwg matrix channel
" I don't know how the insertion step model works in case of mutations. Say, you have an element and it has 3 child elements. That subtree root element is inserted to document tree. Now child 1 has insertion steps which run some script which removes the child and adds it to be the last of the child nodes. So child list is now 2, 3, 1. Do the insertion steps get run on 1 again, because it is now after 2 and 3? I mean, the insertion step would certainly run when 1 is added back to DOM, but would insertion step run again when iterating through the children of the subtree root."

Unless I'm missing something, the pr doesn't match what Blink does. Isn't there a queue here https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/container_node.cc;l=430;bpv=0;bpt=0 ?
So the difference between ScriptRunner and that approach is just that ScriptRunner queues operations and NodeVector is for queuing nodes which have post insertion stuff to run.

The queue mechanism here and the one in Blink have no observable differences. In Blink, all elements with post-insertion steps end up in that queue of nodes to get their steps run. In this PR, all elements with post-insertion steps also run after insertion. Should be no behavioral difference.

I can’t speak to script runners at all since there is no proposal for them, and I don’t really understand them.

There is difference. Blink can deal with DOM mutations if they happen while going through post insertion steps. The PR does not. Blink implementation has that explicit queue of nodes to go through, the PR just vaguely talks about descendants (and doesn't explain what happens if DOM is mutated).

And ScriptRunner is like Blink's implementation, but instead of queuing nodes, one would queue operations (kind of like "nano tasks").

OK thanks for the discussion @smaug----. Anne and I (among others) also discussed this a bit at the last WHATNOT meeting. The latest commit adds a static node list that we populate with all of the inserted nodes. Then we call the post-insertion steps on each of them in that list (if they are connected), so that we don't perform any live tree traversal operations in between post-insertion steps. PTAL!

dom.bs

smaug---- · 2024-05-08T18:22:52Z

dom.bs

+ </li>
+
+ <li><p><a for=list>For each</a> <var>node</var> in <var>staticNodeList</var>, if <var>node</var> is
+ <a>connected</a>, then run the <a>post-insertion steps</a> with <var>node</var>.


(just wondering what should happen, and what browsers do if some earlier post-connected step moves a node, which hasn't get change to run post-connected steps to be elsewhere in the document - so its post-connected steps get run twice. That might be a case to handle separately in each case - but if that is needed, it might be easy to just add is-connected check to the element specific algorithm)

Great scenario. So to make the case more concrete, you're envisioning something like:

Insert (a) script and (b) iframe at the same time.

Both are now in the DOM, but we have not yet made it to the step where we iterate over them and run their post-insertion steps (i.e., the spec step you're commenting on above)

(a) Run the script's post-insertion steps: this moves the iframe around in the DOM. This both:

Re-inserts the iframe into the DOM

Runs the iframe's post-insertion steps

(b) Re-run the iframe's post-insertion steps, even though it exists elsewhere in the DOM now.

Chromium currently runs the post-insertion steps the second time. I think WebKit does the same from looking at their code, but I can't quite re-produce.

Chromium has code that handles this explicitly for iframes here so that we don't try and re-create an iframe's initial document after it has been inserted. And for scripts, I think you would just rely on the already started boolean to not re-execute a script that has already executed due to insertion (Chromium code here).

I lean towards DOM being OK running the post-insertion steps multiple times, and then having per-element checks do the right thing if they don't want to run multiple times. The reason I lean towards this is because I can construct a case where we actually rely on the second invocation of the post-insertion steps doing stuff.

Imagine a case where you insert two scripts at the same time, i.e., document.body.append(script1, script2). script2 has an invalid type and therefore is not executable as-is. script1 does two things:

Moves script2 around in the DOM (thus invoking the second script's post-insertion steps for the first time)

Removes script2's invalid type attribute, making it finally valid (but not immediately executing it)

At least in Chromium, when script2's post-insertion steps run for the second time (as a result of the outermost document.body.append(script1, script2) call finally invoking script2's post-insertion steps), script2 will finally execute. Here's the code snippet:

const script1 = document.createElement('script'); script1.innerText = ` const div = document.querySelector('div'); div.append(script2); script2.removeAttribute('type'); `; const script2 = document.createElement('script'); script2.id = 'script2'; // Makes the script invalid so that it does not run upon insertion. script2.type = 'foo'; script2.innerText = 'console.log("grazie");'; document.body.append(script1, script2);

For some reason WebKit does not run the script, which I think indicates that the post-insertion steps do not run the second time for script2. I would love to know why; @rniwa might know. I might've investigated this over in whatwg/html#10188 but I can't remember off the top of my head. Either way, hopefully this sheds some light on this scenario. WDYT @smaug----

First stab at post-insertion steps

129c030

noamr reviewed Feb 28, 2024

View reviewed changes

dom.bs Outdated Show resolved Hide resolved

dom.bs Outdated Show resolved Hide resolved

dom.bs Show resolved Hide resolved

domfarolino added 2 commits February 29, 2024 16:45

Fixes/review comments

0ceca26

Elaborate on atomicity

164eae9

domfarolino marked this pull request as ready for review March 8, 2024 03:16

domfarolino requested a review from annevk March 8, 2024 03:16

domfarolino mentioned this pull request Mar 8, 2024

Use DOM's post-insertion steps for <script> elements whatwg/html#10188

Open

5 tasks

annevk reviewed Mar 11, 2024

View reviewed changes

dom.bs Show resolved Hide resolved

annevk requested review from rniwa and smaug---- March 13, 2024 12:58

chromium-wpt-export-bot mentioned this pull request Mar 13, 2024

WPT: Script child removal does not trigger execution web-platform-tests/wpt#45085

Merged

smaug---- reviewed Mar 26, 2024

View reviewed changes

dom.bs Outdated Show resolved Hide resolved

domfarolino requested review from smaug---- and annevk March 27, 2024 12:37

past mentioned this pull request Mar 28, 2024

Upcoming WHATNOT meeting on 3/28/2024 whatwg/html#10215

Closed

domfarolino mentioned this pull request Apr 1, 2024

Meta element and DOM post-insertion steps whatwg/html#10241

Open

annevk reviewed Apr 2, 2024

View reviewed changes

dom.bs Outdated Show resolved Hide resolved

dom.bs Outdated Show resolved Hide resolved

dom.bs Show resolved Hide resolved

dom.bs Outdated Show resolved Hide resolved

Address annevk review

2c9f769

domfarolino requested a review from annevk April 4, 2024 03:07

annevk reviewed Apr 4, 2024

View reviewed changes

dom.bs Outdated Show resolved Hide resolved

dom.bs Show resolved Hide resolved

dom.bs Outdated Show resolved Hide resolved

domfarolino added 3 commits April 4, 2024 09:31

Fix indenting

6d3838d

Fix newline

2ffb2de

Fix indentation for real

48d1ee5

annevk added the agenda+ To be discussed at a triage meeting label Apr 10, 2024

past mentioned this pull request Apr 11, 2024

Upcoming WHATNOT meeting on 4/11/2024 whatwg/html#10254

Closed

smaug---- reviewed Apr 11, 2024

View reviewed changes

past removed the agenda+ To be discussed at a triage meeting label Apr 17, 2024

This was referenced Apr 18, 2024

Upcoming WHATNOT meeting on 4/18/2024 whatwg/html#10275

Closed

Upcoming WHATNOT meeting on 4/25/2024 whatwg/html#10287

Closed

domfarolino added 2 commits May 1, 2024 12:11

Static node list

236fe01

Connected

b31d333

domfarolino requested review from annevk and smaug---- May 1, 2024 16:16

smaug---- reviewed May 2, 2024

View reviewed changes

dom.bs Outdated Show resolved Hide resolved

past mentioned this pull request May 3, 2024

Upcoming WHATNOT meeting on 5/2/2024 whatwg/html#10298

Closed

Westbrook mentioned this pull request May 3, 2024

April Face-to-face Scheduling/Agenda WICG/webcomponents#1050

Closed

smaug---- reviewed May 8, 2024

View reviewed changes

past mentioned this pull request May 9, 2024

Upcoming WHATNOT meeting on 5/9/2024 whatwg/html#10318

Closed

Post-connection steps. Also <i> -> <em>

7a06b38

domfarolino changed the title ~~Introduce DOM post-insertion steps~~ Introduce DOM post-connection steps May 13, 2024

cwilso mentioned this pull request May 23, 2024

Upcoming WHATNOT meeting on 5/23/2024 whatwg/html#10352

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Introduce DOM post-connection steps #1261

Introduce DOM post-connection steps #1261

domfarolino commented Feb 28, 2024 •

edited by pr-preview bot

domfarolino commented Mar 8, 2024

domfarolino commented Mar 13, 2024

domfarolino commented Mar 14, 2024 •

edited

rniwa commented Mar 26, 2024

domfarolino commented Mar 26, 2024

rniwa commented Mar 26, 2024

domfarolino commented Mar 27, 2024

domfarolino commented Apr 1, 2024

annevk left a comment

annevk commented Apr 4, 2024

annevk commented Apr 10, 2024

domfarolino commented Apr 11, 2024

smaug---- Apr 11, 2024 •

edited

smaug---- Apr 15, 2024

domfarolino Apr 15, 2024

smaug---- Apr 15, 2024

smaug---- Apr 15, 2024

domfarolino May 1, 2024

smaug---- May 8, 2024

domfarolino May 8, 2024

Introduce DOM post-connection steps #1261

Are you sure you want to change the base?

Introduce DOM post-connection steps #1261

Conversation

domfarolino commented Feb 28, 2024 • edited by pr-preview bot

Footnotes

domfarolino commented Mar 8, 2024

domfarolino commented Mar 13, 2024

domfarolino commented Mar 14, 2024 • edited

rniwa commented Mar 26, 2024

domfarolino commented Mar 26, 2024

rniwa commented Mar 26, 2024

domfarolino commented Mar 27, 2024

domfarolino commented Apr 1, 2024

annevk left a comment

Choose a reason for hiding this comment

annevk commented Apr 4, 2024

annevk commented Apr 10, 2024

domfarolino commented Apr 11, 2024

smaug---- Apr 11, 2024 • edited

Choose a reason for hiding this comment

smaug---- Apr 15, 2024

Choose a reason for hiding this comment

domfarolino Apr 15, 2024

Choose a reason for hiding this comment

smaug---- Apr 15, 2024

Choose a reason for hiding this comment

smaug---- Apr 15, 2024

Choose a reason for hiding this comment

domfarolino May 1, 2024

Choose a reason for hiding this comment

smaug---- May 8, 2024

Choose a reason for hiding this comment

domfarolino May 8, 2024

Choose a reason for hiding this comment

domfarolino commented Feb 28, 2024 •

edited by pr-preview bot

domfarolino commented Mar 14, 2024 •

edited

smaug---- Apr 11, 2024 •

edited