Define focus behavior for <dialog> element with Shadow DOM

[TakayoshiKochi]

The dialog focusing steps algorithm doesn't define well about focusing behavior when Shadow DOM is involved.

See the context at crbug#383230.

[foolip]

On https://crbug.com/383230 I don't see any concrete suggestion of what the spec should do, except from comment 16 where it sounds like it's complicated. Spec prose aside, what is the most desired behavior here?

@hayatoito

[rniwa]

I really hope someone is writing WPT tests for dialog inside a shadow tree.

[foolip]

Tests will be needed to cover the eventual spec change, so that could be a good way to investigate current behavior and illustrate preferred behavior. (Such a PR would be left open until the spec change is reviewed.)

[danbeam]

i'd be happy to write a web platform test regarding the use of shadow DOM in <dialog> if we can come to consensus

[TakayoshiKochi]

@danbeam that is more than welcome! As @foolip commented, such WPTs could fail with current Chrome implementation and should be what it would be specced. The serious usage experience of yours is valuable input for the spec change.

[hayatoito]

Ah, I have found this discussion: #1929
It is too long, and it is hard for me to figure out a progress there.

@danbeam Yeah, wpt would be highly appreciated to understand a desired behavior.

IMO, a sub tree of a dialog element and a document tree should not have any divergent behavior, regarding how focus works, e.g. how autofocus attribute works, or how sequential navigation (Tab-ing) works.
Shadow DOM is not an exception. In either cases, a shadow tree they have should be treated in the same way, as defined in http://w3c.github.io/webcomponents/spec/shadow/#focus, when to define autofocus-ed element or determine the next sequential focus navigated element.

We might also be interested in autofocus and Shadow DOM issue, #833, which has not got much attention recently.

[TakayoshiKochi]

And #1175 seems an umbrella bug for Shadow DOM + <dialog> in general.

[tkent-google]

We should simply change 'descendant' and 'tree order' in 'dialog focusing steps' to shadow-aware concepts, right?

• shadow-including descendant and shadow-including tree order
• Flat tree descendant and order

Which one is preferable?

[tkent-google]

I found Chrome's 'dialog focusing steps' implementation already applied flat tree. Does anyone object to applying flat tree?

[domenic]

We should simply change 'descendant' and 'tree order' in 'dialog focusing steps' to shadow-aware concepts, right?

Right.

Which one is preferable?

Given that autofocus normally uses "inserted into a document" and thus doesn't pierce shadow trees (which I assume is working as intended?), we should probably not use shadow-including.

However, I'm unsure whether flat tree is the right choice here. Should we just use "normal" tree order?

/cc @annevk @smaug----

[domenic]

Given that autofocus normally uses "inserted into a document" and thus doesn't pierce shadow trees (which I assume is working as intended?)

I found #833 which contains some discussion on this point. It seems things are a bit more complicated.

Should we try to treat dialog as if it has delegatesFocus? Maybe solving this should be blocked on implementing the consensus from #833?

[tkent-google]

Given that autofocus normally uses "inserted into a document" and thus doesn't pierce shadow trees (which I assume is working as intended?), we should probably not use shadow-including.

Ah, that's right. Searching shadow trees for autofocus in dialog.show() would be inconsistent.

Maybe solving this should be blocked on implementing the consensus from #833?

Yeah, we should have a consistent solution for this and #833.