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