Don't change focus when re-focusing delegatesFocus shadowhost

[josepharhar]

I was implementing the new dialog shadowdom initial focus goodness when I noticed this in chromium:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/element.cc;l=4714-4718;drc=82b10d45463bbc3d019f5ef981dc8afeb8900a6d

When getting the focusable area of a target, in the case that the target is a shadow-incuding inclusive ancestor of the currently focused element, the spec says to return null, but chromium's implementation returns the currently focused element instead and cites this issue: WICG/webcomponents#840

I'm not certain exactly what the consensus was, but I do see that this spec PR and test was made in response:
#5039
web-platform-tests/wpt#19867 The added test doesn't fail if I return null like the spec says to do, but dialog-focus-shadow-double-nested.html does fail if I return null with this error message:

FAIL showModal() assert_equals: document.activeElement expected Element node <div></div> but got Element node <button tabindex="-1">Focusable</button>

Based on this test failure and reading the WICG issue, I believe that we should be returning the currently focused element, which this patch does.

• At least two implementers are interested (and none opposed):
  • Chrome
  • We can assume others are implemented as this is just a bug fix to previous work that we've agreed on.
• Tests are written and can be reviewed and commented upon at:
  • dialog-focus-shadow-double-nested.html
• Implementation bugs are filed:
  • See bugs filed in Fixes to delegatesFocus #7079.
• MDN issue is filed: N/A

(See WHATWG Working Mode: Changes for more details.)

---

/interaction.html ( diff )

[domenic]

Thank you for the detective work and the neat patch! I'll merge this since it looks like a straightforward bug, and as you noted, there are tests for this case.