[Webkit-unassigned] [Bug 249904] When <summary> is omitted, <details> does not receive keyboard focus.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Aug 29 22:22:06 PDT 2023


https://bugs.webkit.org/show_bug.cgi?id=249904

Michael[tm] Smith <mike at w3.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mike at w3.org

--- Comment #4 from Michael[tm] Smith <mike at w3.org> ---
Is this caused by https://bugs.webkit.org/show_bug.cgi?id=191851?

Does the current code handle focus navigation with shadow trees that have slots?

For the record here, any <details> element in the WebKit DOM includes a user-agent shadow tree with a default <summary> element, like this:

<details>
  <slot name="summarySlot">
    <summary>Details</summary>
  </slot>
</details>

If the document supplies an explicit <summary>, then that explicit summary goes into the DOM in the normal way — but in addition to that default <summary> (and then that explicit <summary> becomes the active summary for that <details>.

But as far as that non-explicit default <summary> element that goes inside that <slot> for every <details>: There’s nothing exceptional about that default <summary> itself; specifically, for that default <summary> — when there’s no other explicit <summary> supplied by the document — isActiveSummary() is true, and so supportsFocus() is true, and defaultTabIndex() is 0.

And if you first click on that <details> element and then hit the tab key, that <summary> will get focus styling. So it’s actually focusable.

But what is exceptional about that <summary> element — unique, even — is that it seems to be the only case in the user-generated shadow DOM where an element goes in as a child of a <slot> like that.

So anyway, all that makes me wonder: Is the cause of this is a general lack of handling yet for focus navigation with shadow trees that have slots?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230830/6d94c1cd/attachment-0001.htm>


More information about the webkit-unassigned mailing list