What happens if the delegated element is also a shadow host with delegatesFocus set

[rniwa]

It seems that the current logic in the focusing step doesn't take into the account the possibility that the first element in the flat tree UA picks might also be a shadow host with delegatesFocus set.

In such cases, don't we need to recursively resolve the delegated element? Neither the spec nor WebKit's implementation has this logic.

The following test case shows that Chrome's current implementation seems to delegate the focus recursively:

const outerHost = document.createElement('div');
const outerShadow = outerHost.attachShadow({mode: 'closed', delegatesFocus: true});

const innerHost = document.createElement('div');
const innerShadow = innerHost.attachShadow({mode: 'closed', delegatesFocus: true});
outerHost.tabIndex = 0;
innerHost.tabIndex = 0;
innerShadow.innerHTML = 'a <span tabindex=0>b</span> c';

document.body.appendChild(outerHost);
outerShadow.append('0 ', innerHost, ' 1');

outerHost.focus();

[rniwa]

@rakina @domenic @smaug---- @annevk

[rakina]

Oh yeah you're right, nice catch. The chrome implementation is already recursive, I'll update the spec tonight.

[rakina]

Oh wait nope I think we're already handling it. Shadow hosts with delegatesFocus=true are explicitly can never be a focusable area (see table under https://html.spec.whatwg.org/multipage/interaction.html#focusable-area).

First in flat tree order will be the same, whether we delegate recursively or not, since flat tree order means we're already gathering everything recursively.

[rniwa]

Hm... that's a good point. I guess we can just add a WPT test for this.

[rakina]

Good idea. @tkent-google can you add a WPT either in Github or Gerrit as part of your focus impl work? (I'm out this week)

[tkent-google]

Ok, here it is: web-platform-tests/wpt#20079

[rniwa]

WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=203869