Simplify popover=hint behaviours & related spec fixes by jakearchibald · Pull Request #12345 · whatwg/html

jakearchibald · 2026-04-08T13:45:02Z

At least two implementers are interested (and none opposed):
- Mozilla
- Google
Tests are written and can be reviewed and commented upon at:
- …
Implementation bugs are filed:
- Chromium: …
- Gecko: …
- WebKit: …
- Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): …
- Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): …
Corresponding HTML AAM & ARIA in HTML issues & PRs:
MDN issue is filed: …
The top of this comment includes a clear commit message to use.

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

Add stuff to infra & use it
Decide on & spec auto-in-hint behaviour
Decide on & spec what happens with popovers shown during beforetoggle-hide.
Review new tests & add more if needed
Apply wrapping

/infrastructure.html ( diff )
/interactive-elements.html ( diff )
/popover.html ( diff )

jakearchibald · 2026-04-08T14:00:08Z

-  <p>To <dfn export data-x="hide-all-popovers-until">hide all popovers until</dfn>, given an <span
-  data-x="HTML elements">HTML element</span> or <code>Document</code> <var>endpoint</var>, a boolean
-  <var>focusPreviousElement</var>, and a boolean <var>fireEvents</var>:</p>
+  <p>To <dfn>hide popover stack until</dfn>, given an <span data-x="html elements">HTML


This needed a rewrite. The previous version looped the wrong way, and assumed popoverList was 'live'.

Thanks, and sorry.

Nahhhhh if anything went wrong here it was in review.

jakearchibald · 2026-04-08T14:01:09Z

I'll sort out the wrapping after reviews & changes.

lukewarlow · 2026-04-08T14:14:41Z

Btw https://github.com/domfarolino/specfmt is quite useful for the wrapping.

jakearchibald · 2026-04-08T15:20:38Z

@lukewarlow haha your deleted comment did reveal a bug! It wasn't the return false that was wrong, but I was missing a return true.

jakearchibald · 2026-04-08T15:29:29Z

Edit: I've broken this out into #12355

av1.mp4

@mfreed7 sorry for another video, but I don't think I'd be able to describe it well. What do you see as the intended behaviour here?

https://random-stuff.jakearchibald.com/bug-repros/popover-show-on-hide-warning/ - here's the demo page.

Edit: I'm not convinced my spec totally solves this either, as hiding a popover hides child popovers, which would include the new ones added, and they'd be hidden with events. Maybe.

annevk · 2026-04-09T07:08:02Z

-  <var>focusPreviousElement</var>, and a boolean <var>fireEvents</var>:</p>
+  <p>To <dfn>hide popover stack until</dfn>, given an <span data-x="html elements">HTML
+  element</span> or null <var>endpoint</var>, <code>Document</code> <var>document</var>,
+  an <span data-x="attr-popover-auto-state">Auto</span> or <span data-x="attr-popover-hint-state">Hint</span> <var>stackType</var>,


I guess we have precedent for using attribute state as a parameter and it's probably reasonable as it's the result of a computation so doesn't depend on any other state.

Yeah, I was unsure about this. I don't mind doing something else.

annevk · 2026-04-09T07:09:40Z

-   data-x="attr-popover-auto-state">Auto</span> state or <var>endpoint</var>'s <code
-   data-x="attr-popover">popover</code> attribute is in the <span
-   data-x="attr-popover-hint-state">Hint</span> state.</p></li>
+   <li><p>Reverse <var>toHide</var>.</p></li>


Reverse also needs an issue or link if it already exists.

whatwg/infra#707

Reminder to self: When I incorporate this, it returns a new list rather than mutating the current list.

jakearchibald · 2026-04-09T12:00:41Z

@mfreed7 can you create a PR for your tests so far?

For whatwg/html#12345.

keithamus · 2026-04-10T09:04:38Z

+       <span>"<code>InvalidStateError</code>"</span> <code>DOMException</code>.</p></li>
+
+       <li><p>Return false.</p></li>
+      </ol>


keithamus · 2026-04-10T10:26:24Z

+  <p>To <dfn>hide popovers until</dfn>, given an <span data-x="html elements">HTML
+  element</span> or null <var>endpoint</var>, <code>Document</code> <var>document</var>,
+  a boolean <var>focusPreviousElement</var>, and a boolean <var>fireEvents</var>:</p>


It might be nice to switch these arguments around, as then it provides a clear signal to implementers that this can be a method on Document.

Suggested change

<p>To <dfn>hide popovers until</dfn>, given an <span data-x="html elements">HTML

element</span> or null <var>endpoint</var>, <code>Document</code> <var>document</var>,

a boolean <var>focusPreviousElement</var>, and a boolean <var>fireEvents</var>:</p>

<p>To <dfn>hide popovers until</dfn>, given <code>Document</code> <var>document</var>, an <span data-x="html elements">HTML

element</span> or null <var>endpoint</var>,

a boolean <var>focusPreviousElement</var>, and a boolean <var>fireEvents</var>:</p>

keithamus · 2026-04-10T10:27:31Z

-   <li><p>Run <span>hide popover stack until</span> given <var>endpoint</var>, <var>document</var>'s
-   <span>showing auto popover list</span>, <var>focusPreviousElement</var>, and
-   <var>fireEvents</var>.</p></li>
+   <li><p>Run <span>hide popover stack until</span> given <var>endpoint</var>, <var>document</var>, <span data-x="attr-popover-auto-state">Auto</span>, <var>focusPreviousElement</var>, and <var>fireEvents</var>.</p></li>


Same here WRT flipping args:

Suggested change

<li><p>Run <span>hide popover stack until</span> given <var>endpoint</var>, <var>document</var>, <span data-x="attr-popover-auto-state">Auto</span>, <var>focusPreviousElement</var>, and <var>fireEvents</var>.</p></li>

<li><p>Run <span>hide popover stack until</span> given <var>document</var>, <var>endpoint</var>, <span data-x="attr-popover-auto-state">Auto</span>, <var>focusPreviousElement</var>, and <var>fireEvents</var>.</p></li>

keithamus · 2026-04-10T10:35:41Z

   data-x="attr-popover-none-state">No Popover</span> state, then set <var>element</var>'s
   <span>previously focused element</span> to <var>originallyFocusedElement</var>.</p></li>

+   <li><p>If <var>originalType</var> is <span data-x="attr-popover-hint-state">Hint</span> and <var>ancestor</var>'s <span>opened in popover mode</span> is "<code data-x="">auto</code>", then set <var>document</var>'s <span>hint stack parent</span> to <var>ancestor</var>.</p></li>


We might need a checkAncestor here due to focus events...

Or we can move this above "Run the popover focusing steps given element"

For whatwg/html#12345. This also changes the definition of clone, since it's just a slice with default arguments.

jakearchibald · 2026-04-14T12:29:28Z

+   <li><p>Let <var>autoPopoverListContainsElement</var> be true if <var>document</var>'s <span>showing auto popover list</span> <span data-x="list contains">contains</span> <var>element</var>.</p></li>
+
+   <li><p>Let <var>hintPopoverListContainsElement</var> be true if <var>document</var>'s <span>showing hint popover list</span> <span data-x="list contains">contains</span> <var>element</var>.</p></li>


Add 'otherwise false'.

mfreed7 · 2026-04-14T19:16:16Z

@mfreed7 can you create a PR for your tests so far?

Yes. Our infra used to file a PR as soon as a Chromium CL went to the review-requested state, but it apparently no longer does that. Since I'm still waiting on the review, the new tests are located here for now:

https://chromium-review.git.corp.google.com/c/chromium/src/+/7727959

jakearchibald · 2026-04-15T08:02:26Z

@mfreed7 cool I'll give them a full review when there's a wpt PR. Could you review this PR?

See this discussion for more context: whatwg/html#12304 whatwg/html#12345 This CL implements a simplified behavioral model for popover=hint and popover=auto, cleanly separating the autoRootedPopoverStack from the hintRootedPopoverStack and introducing a `hintStackParent` to track where the hint stack branches off the auto stack. The new behavior resolves the following inconsistencies (gated behind the `PopoverHintNewBehavior` experimental runtime flag): 1. Opening a hint popover will not hide unrelated auto popovers. 2. Opening a hint popover closes only other non-ancestor hint popovers. 3. Clicking outside consistently closes both auto and hint popovers. 4. Hiding an auto popover closes only its child popovers. 5. Opening an auto popover inside a hint popover is disallowed and will fail. A new WPT test (`popover-hint-hierarchy.html`) is added to explicitly assert these 5 rules, and existing popover WPTs are updated to reflect the new behavior. A virtual test suite (`popover-hint-old-behavior`) is also added to continue testing the legacy behavior. I'm not sure how to best handle the changed tests (and I guess the new test too) in the context of a spec PR that is forthcoming. I'd like to be able to publish (as a WPT PR at least) the changes, to help with the PR effort. Suggestions appreciated. A note about the diff: I made all of the feature flag checks look like `if (!feature enabled) {` in the hopes that the old code would show as unchanged in the diff, but gerrit's diff algorithm isn't great. It's at least a little better like this than if I put the new code first, so I left it. Bug: 4990199 Change-Id: I41d8d96be71ba60ec5e7aa640c935258d1e33431

mfreed7 · 2026-04-15T15:18:52Z

@mfreed7 cool I'll give them a full review when there's a wpt PR. Could you review this PR?

web-platform-tests/wpt#59237

And yes! I've been swamped but I'll give the PR a look right now.

See this discussion for more context: whatwg/html#12304 whatwg/html#12345 This CL implements a simplified behavioral model for popover=hint and popover=auto, cleanly separating the autoRootedPopoverStack from the hintRootedPopoverStack and introducing a `hintStackParent` to track where the hint stack branches off the auto stack. The new behavior resolves the following inconsistencies (gated behind the `PopoverHintNewBehavior` experimental runtime flag): 1. Opening a hint popover will not hide unrelated auto popovers. 2. Opening a hint popover closes only other non-ancestor hint popovers. 3. Clicking outside consistently closes both auto and hint popovers. 4. Hiding an auto popover closes only its child popovers. 5. Opening an auto popover inside a hint popover is disallowed and will fail. A new WPT test (`popover-hint-hierarchy.html`) is added to explicitly assert these 5 rules, and existing popover WPTs are updated to reflect the new behavior. A virtual test suite (`popover-hint-old-behavior`) is also added to continue testing the legacy behavior. I'm not sure how to best handle the changed tests (and I guess the new test too) in the context of a spec PR that is forthcoming. I'd like to be able to publish (as a WPT PR at least) the changes, to help with the PR effort. Suggestions appreciated. A note about the diff: I made all of the feature flag checks look like `if (!feature enabled) {` in the hopes that the old code would show as unchanged in the diff, but gerrit's diff algorithm isn't great. It's at least a little better like this than if I put the new code first, so I left it. Bug: 499019927 Change-Id: I41d8d96be71ba60ec5e7aa640c935258d1e33431 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7727959 Auto-Submit: Mason Freed <masonf@chromium.org> Reviewed-by: David Baron <dbaron@chromium.org> Commit-Queue: David Baron <dbaron@chromium.org> Cr-Commit-Position: refs/heads/main@{#1615186}

annevk

Editorially this looks fine now, thanks for the Infra updates! Please let me know when OP is complete, tests have been reviewed, and at least one person involved did a comprehensive technical review.

annevk · 2026-04-15T15:28:11Z

+             <dfn data-x="list sort descending" data-x-href="https://infra.spec.whatwg.org/#list-sort-in-descending-order">sort in descending order</dfn>
+             <dfn data-x="list slice" data-x-href="https://infra.spec.whatwg.org/#list-slice">slice</dfn> (and its
+             <dfn data-x="list slice from" data-x-href="https://infra.spec.whatwg.org/#list-slice-from">from</dfn> and
+             <dfn data-x="list slice to" data-x-href="https://infra.spec.whatwg.org/#list-slice-to">to</dfn> options), and


Suggested change

<dfn data-x="list slice to" data-x-href="https://infra.spec.whatwg.org/#list-slice-to">to</dfn> options), and

<dfn data-x="list slice to" data-x-href="https://infra.spec.whatwg.org/#list-slice-to">to</dfn> arguments), and

See this discussion for more context: whatwg/html#12304 whatwg/html#12345 This CL implements a simplified behavioral model for popover=hint and popover=auto, cleanly separating the autoRootedPopoverStack from the hintRootedPopoverStack and introducing a `hintStackParent` to track where the hint stack branches off the auto stack. The new behavior resolves the following inconsistencies (gated behind the `PopoverHintNewBehavior` experimental runtime flag): 1. Opening a hint popover will not hide unrelated auto popovers. 2. Opening a hint popover closes only other non-ancestor hint popovers. 3. Clicking outside consistently closes both auto and hint popovers. 4. Hiding an auto popover closes only its child popovers. 5. Opening an auto popover inside a hint popover is disallowed and will fail. A new WPT test (`popover-hint-hierarchy.html`) is added to explicitly assert these 5 rules, and existing popover WPTs are updated to reflect the new behavior. A virtual test suite (`popover-hint-old-behavior`) is also added to continue testing the legacy behavior. I'm not sure how to best handle the changed tests (and I guess the new test too) in the context of a spec PR that is forthcoming. I'd like to be able to publish (as a WPT PR at least) the changes, to help with the PR effort. Suggestions appreciated. A note about the diff: I made all of the feature flag checks look like `if (!feature enabled) {` in the hopes that the old code would show as unchanged in the diff, but gerrit's diff algorithm isn't great. It's at least a little better like this than if I put the new code first, so I left it. Bug: 4990199 Change-Id: I41d8d96be71ba60ec5e7aa640c935258d1e33431 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7727959 Auto-Submit: Mason Freed <masonf@chromium.org> Reviewed-by: David Baron <dbaron@chromium.org> Commit-Queue: David Baron <dbaron@chromium.org> Cr-Commit-Position: refs/heads/main@{#1615186}

mfreed7

This looks pretty good to me. Thanks again for putting it together.

mfreed7 · 2026-04-15T15:25:40Z

   false, <var>throwExceptions</var>, and null is false, then return.</p></li>

+   <li>
+    <p>Let <var>checkAncestor</var> be the following steps:</p>


Are inline algorithms like this camelCase? (I know we already have cleanupShowingFlag here, but it just looked funny right next to "running check popover validity".)

Variables are always camelCase, regardless of what they hold.

Something ending in Flag sounds wrong, especially in new prose.

Ahh ok, thanks. The cleanupShowingFlag was here before, but I guess now's a great time to rename it?

mfreed7 · 2026-04-15T15:45:14Z

   construction of a well-formed tree from the (possibly cyclic) graph of connections. Only <span
-   data-x="attr-popover-auto-state">Auto</span> popovers are considered.</p>
+   data-x="attr-popover-auto-state">Auto</span> and <span
+   data-x="attr-popover-hint-state">Hint</span> popovers are considered.</p>


Thanks for this fix.

mfreed7 · 2026-04-15T15:51:59Z

-    <ol>
-     <li><p>Run <span>close entire popover list</span> given <var>document</var>'s <span>showing
-     hint popover list</span>, <var>focusPreviousElement</var>, and <var>fireEvents</var>.</p></li>
+   <li><p>If <var>endpointIsHint</var>, then return.</p></li>


So with this behavior, if you have an Auto popover (A1), which opens a Hint popover (H1). You also have another Auto popover (A2) opened higher/later in the auto stack. The user clicks inside H1. I thought (and implemented) that in this case, A2 should be closed, because A1 is H1's hint stack parent. But this algorithm won't do that. Is that intentional? Your proposal says "Proposed: All auto/hint popovers are closed except any clicked popover and its parents."

mfreed7 · 2026-04-15T15:57:59Z


-   <li>
-    <p>Perform the following steps at least once:</p>
+   <li><p>Let <var>lastHideIndex</var> be 0 if <var>popoverList</var> does not <span data-x="list contains">contain</span> <var>endpoint</var>; otherwise the index of <var>endpoint</var> in <var>popoverList</var> plus 1.</p></li>


I think in reading this, I think I caught a bug in my Chromium impl, which might mean I also wrote the corresponding bug into the WPTs. I'll take a look there, but you might find it also as you review, so FYI.

mfreed7 · 2026-04-15T16:13:38Z


-     <li><p>Let <var>candidatePosition</var> be
-     <var>popoverPositions</var>[<var>candidateAncestor</var>].</p></li>
+   <li><p>Let <var>ancestorIndex</var> be the minimum of <var>popoverAncestorIndex</var> and <var>sourceAncestorIndex</var>.</p></li>


I think perhaps this should be the maximum not the minimum? Scenario:

<div id=A1 popover=auto>A1 <button id=buttonA2 popovertarget=A2>Open A2</button> <div id=A3 popover=auto>A3</div> </div> <div id=A2 popover=auto>A2 <button id=buttonA3 popovertarget=A3>Open A3</button> </div> <script> A1.showPopover(); buttonA2.click(); buttonA3.click(); // <-- difference here </script>

When A2 is opened, A1 is its ancestor (via popovertarget=A2). When A3 is opened, it can either have A1 as its ancestor (via DOM) or A2 as its ancestor (via popovertarget=A3). I think the reference higher up in the stack should probably win here. As written, the spec will close A2, even though its button opened A3.

{When I fix the Chromium bug above, I'll be sure to add a test case like this to a WPT.}

mfreed7 · 2026-04-15T16:15:28Z

-  <p>To <dfn export data-x="hide-all-popovers-until">hide all popovers until</dfn>, given an <span
-  data-x="HTML elements">HTML element</span> or <code>Document</code> <var>endpoint</var>, a boolean
-  <var>focusPreviousElement</var>, and a boolean <var>fireEvents</var>:</p>
+  <p>To <dfn>hide popover stack until</dfn>, given an <span data-x="html elements">HTML


Thanks, and sorry.

mfreed7 · 2026-04-15T16:36:12Z

+
+      <p class="note">These checks are performed again because running <span>hide popover stack until</span> above could have fired the <code data-x="event-beforetoggle">beforetoggle</code> event, and an event handler could have altered DOM state.</p>
+     </li>
+


I think it's possible there's a missing case here too. The beforetoggle could have opened a fresh hint, and this code will allow it to stay on the hint stack while still opening the new (unrelated) auto. Example:

<div id=A1 popover=auto>A1</div> <div id=A2 popover=auto>A2</div> <div id=H1 popover=hint>H1</div> <script> A1.showPopover(); A1.onbeforetoggle = () => H1.showPopover(); A2.showPopover(); </script>

I'll add a WPT for this too. I think the fix it maybe to just check right here that the hint stack is still empty before proceeding?

mfreed7 · 2026-04-15T22:34:58Z

The new tests I referred to above are here now: https://crrev.com/c/7765209. I'll comment again when those become a WPT PR.

This fixes an error in the recently-landed popover=hint behavior at [1], for this case: Auto popover (A1) is the anchor for a Hint popover (H1). Another Auto popover (A2) is opened on top. The Auto stack is [A1, A2] and the hint_parent is A1. While hiding all popovers down to A1, the old code would hide H1, even though it left H1's anchor (A1) open. It also adds two tests for cases discovered during the review of the spec PR [2]. Those were correct in Chromium, but incorrect in the spec. [1] https://crrev.com/c/7727959 [2] whatwg/html#12345 Bug: 499019927 Change-Id: I917bf939614f9811470444e9f13c942e5c63b1b1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7765209 Auto-Submit: Mason Freed <masonf@chromium.org> Reviewed-by: David Baron <dbaron@chromium.org> Commit-Queue: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1616163}

jakearchibald added 4 commits April 8, 2026 13:45

Show popover fixed

04c3483

The rest of the owl

f4714ea

No need to set hideUntil to document

3bca74f

Another document set

dc41ca8

jakearchibald commented Apr 8, 2026

View reviewed changes

jakearchibald marked this pull request as ready for review April 8, 2026 14:01

jakearchibald requested review from keithamus, lukewarlow and mfreed7 April 8, 2026 14:01

Missing return true

4518fd0

jakearchibald mentioned this pull request Apr 8, 2026

What should happen if you open an auto popover 'within' a hint popover? #12346

Open

annevk reviewed Apr 9, 2026

View reviewed changes

This was referenced Apr 9, 2026

Add list slice whatwg/infra#706

Merged

Add list reverse whatwg/infra#707

Merged

jakearchibald commented Apr 9, 2026

View reviewed changes

Comment thread source Outdated

jakearchibald added 5 commits April 9, 2026 11:38

Minor changes

e345ff0

Hint first, and make it clear the conditions are exclusive

8f4f8fd

Actually remove the TODO lol

31a54ee

Create algo for closing hint then auto popovers

afc6003

Fixing silly mistakes

d2fd3f5

jamesnw mentioned this pull request Apr 9, 2026

Update popover=hint to match spec changes oddbird/popover-polyfill#275

Open

keithamus mentioned this pull request Apr 9, 2026

Should the popoverList in "hide popover stack until" and "close entire popover list" be dynamically updated? #11007

Open

annevk pushed a commit to whatwg/infra that referenced this pull request Apr 10, 2026

Add list reverse

7f8c8ee

For whatwg/html#12345.

Don't hide autos if endpoint is in the hint stack

657f638

keithamus reviewed Apr 10, 2026

View reviewed changes

jakearchibald mentioned this pull request Apr 10, 2026

What should happen if a popover is shown during the hide of another? #12355

Open

annevk pushed a commit to whatwg/infra that referenced this pull request Apr 14, 2026

Add list slice

994009c

For whatwg/html#12345. This also changes the definition of clone, since it's just a slice with default arguments.

jakearchibald commented Apr 14, 2026

View reviewed changes

Use infra list slice & reverse

84eee6f

chromium-wpt-export-bot mentioned this pull request Apr 15, 2026

Implement new/revised popover=hint behavior web-platform-tests/wpt#59237

Open

annevk approved these changes Apr 15, 2026

View reviewed changes

mfreed7 approved these changes Apr 15, 2026

View reviewed changes

	<li><p>Run <span>hide popover stack until</span> given <var>endpoint</var>, <var>document</var>, <span data-x="attr-popover-auto-state">Auto</span>, <var>focusPreviousElement</var>, and <var>fireEvents</var>.</p></li>
	<li><p>Run <span>hide popover stack until</span> given <var>document</var>, <var>endpoint</var>, <span data-x="attr-popover-auto-state">Auto</span>, <var>focusPreviousElement</var>, and <var>fireEvents</var>.</p></li>

		<li><p>Let <var>autoPopoverListContainsElement</var> be true if <var>document</var>'s <span>showing auto popover list</span> <span data-x="list contains">contains</span> <var>element</var>.</p></li>

		<li><p>Let <var>hintPopoverListContainsElement</var> be true if <var>document</var>'s <span>showing hint popover list</span> <span data-x="list contains">contains</span> <var>element</var>.</p></li>

	<dfn data-x="list slice to" data-x-href="https://infra.spec.whatwg.org/#list-slice-to">to</dfn> options), and
	<dfn data-x="list slice to" data-x-href="https://infra.spec.whatwg.org/#list-slice-to">to</dfn> arguments), and


		<p class="note">These checks are performed again because running <span>hide popover stack until</span> above could have fired the <code data-x="event-beforetoggle">beforetoggle</code> event, and an event handler could have altered DOM state.</p>
		</li>

Conversation

jakearchibald commented Apr 8, 2026 • edited by pr-preview bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

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!

jakearchibald commented Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lukewarlow commented Apr 8, 2026

Uh oh!

jakearchibald commented Apr 8, 2026

Uh oh!

jakearchibald commented Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

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!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jakearchibald commented Apr 9, 2026

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!

mfreed7 commented Apr 14, 2026

Uh oh!

jakearchibald commented Apr 15, 2026

Uh oh!

mfreed7 commented Apr 15, 2026

Uh oh!

annevk left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mfreed7 left a comment

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!

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

jakearchibald commented Apr 8, 2026 •

edited by pr-preview bot

Loading

jakearchibald commented Apr 8, 2026 •

edited

Loading

jakearchibald commented Apr 8, 2026 •

edited

Loading