Intent to Ship: Popover=hint behavior changes

[Mason Freed]

Contact emails

mas...@chromium.org

Explainer

No information provided

Specification

https://github.com/whatwg/html/pull/12345

Summary

This change implements a revised and simplified stacking model for the popover=hint attribute and its interactions with popover=auto. Previously, the interactions between these two types of popovers could be complex in some corner case situations (such as nesting auto popovers inside hint popovers), and could lead to unexpected behavior. Under the new model, opening a hint popover will no longer inadvertently close unrelated auto popovers. Hint popovers are now only hidden when their ancestral auto popover is hidden, or when a new, unrelated auto popover is opened. Additionally, developers can now safely nest an auto popover inside a hint popover; instead of throwing an exception or breaking the stack, the nested auto popover will gracefully "downgrade" and behave as a hint popover. This allows use cases such as placing a customizable-<select> within a popover=hint. To further improve predictability and prevent complex state mutations, we are also tightening the behavior around opening and closing popovers from within the beforetoggle event. There were guards in place for some, but not all, of the possible cases before. This change revamps the mechanism used to detect these cases, so that it should more reliably throw InvalidStateErrors for all such cases. This ensures that popover state management remains stable and prevents looping reentrancy bugs. All of these changes were motivated by standards conversations with Mozilla on the spec PR here: https://github.com/whatwg/html/pull/12345.

Blink component

Blink>DOM

Web Feature ID

popover-hint

Motivation

These changes are the result of a conversation in standards that came up as other browsers started to review the landed specs for the popover=hint feature. It is unfortunate that this detailed review didn't happen at the time of the landing of the specs, or the shipping of this feature in Chrome, but it's good that it eventually did happen. The changes are positive ones that rationalize the behavior in various corner-case situations, with multiple nested stacks of popovers.

Initial public proposal

https://github.com/whatwg/html/issues/12304

Search tags

popover, hint

TAG review

No information provided

TAG review status

Not applicable

Goals for experimentation

None

Risks

Interoperability and Compatibility

These changes are very unlikely to cause behavioral changes on existing sites. The popover=hint attribute value is a relatively new addition to the Popover API, and there is minimal usage (0.025% https://chromestatus.com/metrics/feature/timeline/popularity/4480) in the wild. For those sites that have already started adopting popover=hint, these updates address edge cases and structural inconsistencies, meaning any observed differences will very likely be strict improvements to the usability of the API in these corner case situations. We will monitor carefully for any bug reports, and we can address them as they arise.

Gecko: Positive (https://github.com/whatwg/html/pull/12345) Proposed changes came from Mozilla.

WebKit: Positive (https://github.com/whatwg/html/pull/12345#pullrequestreview-4114820129)

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided

Debuggability

No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

Flag name on about://flags

No information provided

Finch feature name

PopoverHintNewBehavior

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://crbug.com/499019927

Estimated milestones

Shipping on desktop	150
DevTrial on desktop	149
Shipping on Android	150
DevTrial on Android	149
Shipping on WebView	150

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

No information provided

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6282804208992256?gate=4782991999107072

This intent message was generated by Chrome Platform Status.

[Jake Archibald]

On Friday, 24 April 2026 at 12:01:27 UTC-4 mas...@chromium.org wrote:

It is unfortunate that this detailed review didn't happen at the time of the landing of the specs, or the shipping of this feature in Chrome, but it's good that it eventually did happen.

Yeah, +1 to this. It's a complicated feature building on a complicated feature, so there being rough edges in the initial spec aren't surprising, so the 'failure' here is entirely in review by others.

I noticed these issues when I tried to document the differences between popover=auto and popover=hint, and discovered that I couldn't make it make sense. Behaviours would flip unexpectedly, and I couldn't justify why those behaviours existed. I was surprised that it felt like I was the first person to review this feature in this detail (i.e., just below the surface).

This level of review should have happened within Chrome, but it also should have happened by other orgs.

My guess is that, given the spec is complicated, it was difficult to figure out the resulting behaviours from the spec, so it was missed in the HTML PR. When I came to it, I had the advantage of two implementations to play with. But that could have been done much sooner.

That aside, I'm really happy how this has turned out. I know it's a pain in the arse to revisit this stuff after it feels 'done', so I'm really grateful to Mason for working on it.

Jake.