[tooltip] Escape stack broken for unfocused Tooltip inside Dialog

[hoiheart]

Bug report

Current behavior

When there is a tooltip inside a dialog, if the tooltip is opened without focus on the tooltip trigger and ESC is pressed, the tooltip's handleOpenChange does not fire. Instead, the dialog's handleOpenChange fires immediately, making escape stack control impossible.

Reproducible example

https://codesandbox.io/p/sandbox/4s92t5

Base UI version

v1.1.0

Which browser are you using?

Chrome

Which OS are you using?

Mac OS

[atomiks]

This seems kind of ambiguous because of the mix of user input (pointer vs. keyboard). The pointer hovering the tooltip doesn't necessarily mean you want Esc dismissal to be "limited" to the tooltip, because keyboard control is often tightly coordinated with focus. Do you have examples of other libs treating pointer as "has focus" for Esc dismissal?

Implementation-wise, the reason this happens is because the onKeyDown listener fires on whatever control has focus, which can block parent keydown listeners (event.stopPropagation()) from firing (which ties into my point above about keyboard control and focus being linked). But if focus isn't on the control, this doesn't happen, which leads to the issue present.

[hoiheart]

@atomiks

For hover-based components (tooltips, hover card), I think there are cases where users use a combination of keyboard and mouse.

The part I found confusing was that even when the trigger is not focused, the behavior and event firing differed between a tooltip in the root (A) and a tooltip inside a dialog (B).

For the current behavior of B, I think it might be possible to work around it by adding a separate global keydown event to first check whether the trigger is inside the dialog and guard accordingly. However, before resorting to custom handling, this appeared to be an issue with base-ui's behavior, so I wanted to report it.