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:
- Implement new/revised popover=hint behavior web-platform-tests/wpt#59237
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.)

Fixes #12304.

Fixes #12346.

Fixes #12355.

Fixes #12356.

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

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>


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 <[email protected]> Reviewed-by: David Baron <[email protected]> Commit-Queue: David Baron <[email protected]> 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.

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 <[email protected]> Reviewed-by: David Baron <[email protected]> Commit-Queue: David Baron <[email protected]> Cr-Commit-Position: refs/heads/main@{#1615186}

mfreed7

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

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

If I'm understanding you correctly, you're talking about a structure like this:

graph TD A1 --> A2 A1 --> H1

Loading

…where H1 is clicked.

Ah, yeah, good catch. It'll stop here and not hide A2.

Fixed in 3e4a889

Right, that's the tree. But I think maybe there's another similar problem still there. With that tree (and A1 being the "hint stack parent"), if you go to open a new A3 (whose invoker is inside A1). During that show (A3.showPopover()), the "topmost popover ancestor" will find A1 to be that ancestor, and we will call "hide popovers until" on A1. But the new "hide popovers until" will first call "hide popover stack until" with A1. Because A1 is in the auto stack, that algorithm will slice the entire hint stack and close it. H1 gets closed, and I think it should stay open.

WDYT? I will add a WPT test case for this, if there isn't one already.

I thought that opening an auto popover always hides hint popovers? That's what I outlined here anyway #12304 (comment)

Or have I misunderstood?

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 <[email protected]> Reviewed-by: David Baron <[email protected]> Commit-Queue: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1616163}

jakearchibald · 2026-04-17T15:19:46Z

@keithamus and @mfreed7, hopefully this is it in terms of the behaviour. Aside from editorial stuff, I've changed:

Light dismiss (click behaviour) is changed so it correctly closes unrelated auto popovers if a hint is clicked.
Topmost popover ancestor algorithm should be doing the correct thing now.
Opening a hint popover within an auto popover now downgrades the popover to hint, and allows it to open.
Showing a popover during the show/hide of another is no longer allowed.

On that last point, I was pretty heavy-handed, and applied it to all popovers, not just auto/hint. Otherwise, it gets tricky if the popover type changes.

Thank you for all the reviews so far. Up for one more?

I'll take a look at the tests.

mfreed7 · 2026-04-17T17:20:01Z

@keithamus and @mfreed7, hopefully this is it in terms of the behaviour.

Thanks again for taking this on!

Opening a hint popover within an auto popover now downgrades the popover to hint, and allows it to open.

This bit is not yet represented in the WPTs, FYI. I don't think I can get to it today, but maybe. Let me know if you edit the WPTs in the meantime. All of the rest should be represented (modulo my note below).

On that last point, I was pretty heavy-handed, and applied it to all popovers, not just auto/hint. Otherwise, it gets tricky if the popover type changes.

I think that's fine. Exceptions are better than confusing situations - they lead to the well lit path.

Thank you for all the reviews so far. Up for one more?

I'll look right now.

I'll take a look at the tests.

Thanks! Note that this set of changes landed in Chromium, but hasn't been put up as a WPT PR yet. I think our infra is having a problem. I've pinged them.

mfreed7 · 2026-04-17T19:39:32Z

Thank you for all the reviews so far. Up for one more?

I'll look right now.

I think the new changes look good, modulo the one I re-opened and commented on. Otherwise, great! I'm getting started on the new/changed WPTs corresponding to the auto-downgrades-to-hint and "loop" prevention stuff.

mfreed7 · 2026-04-17T21:11:43Z

Complete aside: it's cool and it's also a problem that you've grabbed PR #12345. My LLM wrote that into a comment, and I just naturally assumed it hallucinated the number.

mfreed7 · 2026-04-17T22:24:19Z


-  <p>Every <span data-x="HTML elements">HTML element</span> has a <dfn>popover showing or
-  hiding</dfn>, which is a boolean, initially set to false.</p>
+  <p>Every <span data-x="HTML elements">HTML element</span> has a <dfn>popover hiding</dfn>, which is a boolean, initially set to false.</p>


Did you mean to put this bit on Element and not Document? Having it here on Element means you can open a new popover from within the events for another popover, e.g.,

<div id="popoverA" popover="auto">A</div> <div id="popoverB" popover="auto">B</div> <script> popoverA.addEventListener('beforetoggle', (e) => { popoverB.showPopover(); // This runs while popover A is half way open }); popoverA.showPopover(); <script>

Here, popoverB tries to close popoverA before popoverA has finished opening. I think the end state is maybe ok in this case, but it makes me nervous that this is a path to bugs. It seems like maybe this bit should live on Document, next to "hiding popover nesting count"?

Or I'm entirely missing the nuance of the new algorithms.

This is an existing concept for preventing events on a nested hide of a single popover. I simply renamed it because it previously handled nested showing, but that isn't possible anymore.

There's an additional document-level thing for preventing showing within a show.

jakearchibald · 2026-04-18T03:46:42Z

+
+  <p>Every <code>Document</code> has a <dfn>hiding popover nesting count</dfn>, which is a number, initially 0.</p>
+
+  <p>Every <code>Document</code> has a <dfn>showing popover</dfn>, which is a boolean, initially false.</p>


@mfreed7 this is the concept

jakearchibald · 2026-04-18T03:47:27Z

+   <li><p>Let <var>document</var> be <var>element</var>'s <span>node document</span>.</p></li>
+
+   <li>
+    <p>If <var>document</var>'s <span>showing popover</span> is true, or <var>document</var>'s <span>hiding popover nesting count</span> is not 0, then:</p>


@mfreed7 here's where it's used.

jakearchibald · 2026-04-20T18:32:21Z

@mfreed7

Complete aside: it's cool and it's also a problem that you've grabbed PR #12345. My LLM wrote that into a comment, and I just naturally assumed it hallucinated the number.

Yes! It was really satisfying to grab #12345. Even more-so because, when I noticed the original issue was #12304, I thought "ohhhh, #12345 will be soon! I wonder what that will be".

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

Comment thread source Outdated

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

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

Comment thread source Outdated

mfreed7 approved these changes Apr 15, 2026

View reviewed changes

jakearchibald added 10 commits April 17, 2026 12:00

Change arg order of popover hide

7a71186

Set hint stack branch earlier

470b816

Add missing 'otherwise's

f6816de

options to arguments

2dbb9bf

Rename cleanupShowingFlag to cleanupShowingSteps

4937655

Correct popover click behavior

3e4a889

Fix topmost popover ancestor

acfe14a

Allow auto within hint by downgrading to hint

0f6701f

Disallow showing a popover while another is showing

f99432c

Prevent showing a popover during the show or hide of another popover

7ca5f3d

mfreed7 reviewed Apr 17, 2026

View reviewed changes

jakearchibald commented Apr 18, 2026

View reviewed changes


		<p>Every <code>Document</code> has a <dfn>hiding popover nesting count</dfn>, which is a number, initially 0.</p>

		<p>Every <code>Document</code> has a <dfn>showing popover</dfn>, which is a boolean, initially false.</p>

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!

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!

Uh oh!

Uh oh!

Uh oh!

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!

Uh oh!

Uh oh!

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!

Uh oh!

mfreed7 left a comment

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!

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!

mfreed7 commented Apr 15, 2026

Uh oh!

jakearchibald commented Apr 17, 2026

Uh oh!

mfreed7 commented Apr 17, 2026

Uh oh!

mfreed7 commented Apr 17, 2026

Uh oh!

mfreed7 commented Apr 17, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jakearchibald Apr 18, 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!

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

jakearchibald Apr 18, 2026 •

edited

Loading