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

[JanMiksovsky]

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:

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

And suppose this custom element receives some light DOM children:

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

Repro: https://jsbin.com/qivoheg/edit

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. Now that we've hit the same issue in Safari, we're wondering if this could be addressed more formally.

[rniwa]

That definitely sounds like a bug in Safari & Chrome. Focus in general isn't well spec'ed in HTML (I think the person who was working on that at Google has since left), but Gecko's behavior makes a lot more sense to me.

[JanMiksovsky]

@rniwa Thanks. Shall I file a WebKit bug, or would you prefer to do that?
@hayatoito From your comments on the linked Chromium bug, it sounds like you support fixing this as well. Can you confirm?

[rniwa]

Yeah, it would be great if you can file a bug. That way, you can follow along the progress we make.

[hayatoito]

@JanMiksovsky Yeah, I think we should clarify the behavior in the spec sooner or later, however, I agree that we should align the behavior with Firefox in this case.

cc: @rakina

[JanMiksovsky]

@rniwa Filed as https://bugs.webkit.org/show_bug.cgi?id=191694.

[JanMiksovsky]

@hayatoito The Chromium and WebKit bugs are now tracking the actual fixes, which is what I'm interested in. I'll let you decide whether you want to leave this issue here open (to track the need to update the spec) or, since we're all in agreement, would prefer to close this issue (and track the spec update somewhere else).

[hayatoito]

@JanMiksovsky Yeah, I think the motivation you filed an issue here would be to let Chromium and Blink fix the implementations. :) I think you succeeded well. Let me close the issue, though we might want to track the spec update somewhere, as you mentioned.

[rniwa]

I think we should keep this issue open we have a relevant spec fixed.

[hayatoito]

I think this should be tracked on whatwg/html, rather than w3c/webcomponents, as part of whatwg/html#2013, or other issues about focus there.

[hayatoito]

@JanMiksovsky

Just FYI.

As README.md file in this repository says:

Please file issues in the most specific repository possible,

It would be better to file an issue for whatwg/html. Basically, please don't use this webcomponents repository for any new issue. The most spec work should be done in whatwg/dom or whatwg/html.

[rniwa]

That's fine. I think we just need to file an issue probably in https://github.com/whatwg/html/issues/, and then reference that issue, and close this one.