Toolbar Active control blur/focus-out events not happening when clicking within in Edge and Chrome

[aagash-ni]

🐛 Bug Report

In Chrome and Edge, when a control (e.g., a button or text field) within a toolbar is focused or active, clicking anywhere else within the toolbar does not blur the currently active control or set its value. However, clicking outside the toolbar works as expected and blurs the active control.

This behavior functions correctly in Firefox, where clicking within the toolbar properly blurs the active control.

💻 Repro or Code Sample

• Click on any element inside the toolbar to make it focused or active.
• Then, click on any other area within the toolbar to blur or remove focus from the currently active control.

🤔 Expected Behavior

• clicking on any area within the toolbar should blur or remove focus from the currently active control, just as it does when clicking outside the toolbar.

😯 Current Behavior

• Clicking within the toolbar does not blur or focus out the currently active control

🔦 Context

Discussion link: https://dev.azure.com/ni/DevCentral/_git/Skyline/pullRequest/850146#1733521296

🌍 Your Environment

• OS: Windows
• Browser: Microsoft Edge, Google Chrome, Mozilla FireFox

[mollykreis]

I'm not sure why the behavior is different between chromium and FF (I haven't looked for any issues filed to either browser), but the difference seems to be tied to delegatesFocus: true being set on the toolbar. With delegatesFocus: false, both browsers behave as described as the "Expected Behavior".

[rajsite]

From mdn

If true, when a non-focusable part of the shadow DOM is clicked, or .focus() is called on the host element, the first focusable part inside the host's shadow DOM is given focus

So sounds like Chrome is behaving right for delegatesFocus: true based on the mdn description.

I think setting delegatesFocus: false / keeping it unset seems reasonable for the toolbar. The toolbar shadow root doesn't have anything focusable, it's all light dom stuff that was slotted that has focus. Curious if changing that setting messes with the roving tabindex behavior in unexpected ways.