[w3c/webcomponents] mousedown on a light DOM element should be able to focus on a shadow container (#773)

mousedown on a light DOM element should be able to focus on a shadow container

We've run into some inconsistent and surprising behavior in the way implicit focus-on-mousedown behavior works across the shadow boundary.

Consider a custom element whose shadow contains a focusable element that contains a slot:

```html
<test-element>
  #shadow-root
    <div tabindex="0">
      <slot></slot>
    </div>
</test-element>
```

And suppose this custom element receives some light DOM children:

```html
<test-element>
  <span>Click me</span>
</test-element>
```

Repro: https://jsbin.com/qivoheg/edit?html,output


What happens if the user clicks inside the "Click me" span in the light DOM?

As far as we can determine, the standard default behavior of a `mousedown` event is to focus on the nearest focusable ancestor of the event target — but should that nearest ancestor take into account the composed tree?

* In Firefox, the focus appears to travel up the composed tree. Even when the user clicks a light DOM child of the custom element, Firefox finds the focusable container of the slot inside the custom element's shadow and puts the focus there. This feels correct.
* In Chrome and Safari, the focus only travels up the light DOM tree. Hence, clicks on a light DOM child do not give focus to the custom element, and the focus is lost (the document body gets the focus). This feels surprising.

We find ourselves needing to normalize the behavior of `mousedown` to achieve Firefox's default behavior in all browsers so that our components can properly support the keyboard and ARIA.

Here we're focusing on the question of how `mousedown` should implicitly set keyboard focus. As far as we can tell, this issue is distinct from earlier discussions of tab navigation through focusable shadow elements, and from whether focusing on a shadow host should be able to delegate focus to an inner focusable element.

We had originally thought the issue was limited to Chrome, and filed a related [Chromium bug](https://bugs.chromium.org/p/chromium/issues/detail?id=894931). Now that we've hit the same issue in Safari, we're wondering if this could be addressed more formally.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/773