Size Change: +33 B (0%)

Total Size: 1.17 MB

_{compressed-size-action}

I think the main issue is that for DOM specific events where we rely on DOM bubbling instead of React event bubbling, we should rely on DOM events addEventListener and not React handlers.

In other words, I think the issues is not in the inspector and the inspector should always use bubblesVirtually. The issue instead is in withFocusOutside where it should use DOM events and not React events.

The issue instead is in withFocusOutside where it should use DOM events and not React events.

@youknowriad Though blur doesn't bubble IIRC, which this component depends on. I wonder if it may also cause some issues with nested popovers if it was implemented with DOM event listeners as blur events would occur outside the originating popover.

@talldan Can we rely on event capturing maybe?

We could give it a try, but there's a risk it might break existing uses of withFocusOutside that rely on the event bubbling virtually.

I wonder if it may also cause some issues with nested popovers if it was implemented with DOM event listeners as blur events would occur outside the originating popover.

Don't we already have some issues with nested popovers/modals not closing when expected? Maybe worth checking if this would actually fix them 😅

@youknowriad @tellthemachines Here's a quick test of that - 65c5a6b

It looks like there are some issues with the nested popovers in #24304, but maybe as you say some kind of event capturing could solve that.

there's a risk it might break existing uses of withFocusOutside that rely on the event bubbling virtually.

conceptually, it seems that withFocusOutside shouldn't rely on React event bubbling anyway. I'm having a hard time thinking about any potential use-case there. Doesn't mean it doesn't exist though.

@talldan Can we try that on a PR and see how it looks?

I didn't mention but omitting event bubbling in the inspector breaks the inspector for folks using RichText on the inspector.