Elements inside `::details-content` cannot be focussed with tab
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox143 | --- | fixed |
People
(Reporter: keithamus, Assigned: keithamus)
References
Details
Attachments
(1 file)
Given
<!DOCTYPE html>
<details>
<summary>First</summary>
<p>Then <a href=https://mozilla.org>Second</a></p>
</details>
Finally <button>Third</button>
Running with the pref disabled:
- Open page
- Click "First"
- Press tab
- Observe "Second" is focussed
- Press tab
- Observe "Third" is focussed
Running with pref enabled:
- Open page
- Click "First"
- Press tab
- Observe "Third" is focussed
|
Assignee | |
Comment 1•9 months ago
|
||
In GetNextTabbableContentInScope we iterate over content, trying to find
the next tabbable content within the scope. With the next peice of
iterable content we first check if it is IsInNativeAnonymousSubtree and
if it has a PrimaryFrame, and if so check that frames tabIndex. If the
element does not have a frame we then check the host/slot tabindex.
Finally if it's not a host/slot we check the primary frame (again).
This means for slots with a display:contents value, they'll have no
frame and they'll drop to the next condition (IsHostIsSlot), however
for slots with a frame (e.g. display:block) they'll use the frames
tabIndex value.
For a slot element with display:block this means we're reliant on the
primary frame's focusability, but this is an incorrect flow of logic
because it means that the slot with display:block is skipped - one such
element exists: the ::details-content pseudo.
By simply removing this check, and letting the else block resolve the
primary frame's tabIndex, we can correctly ensure ::detils-content
children can be focused.
|
||
Comment 4•9 months ago
|
||
| bugherder | ||
|
||
Updated•8 months ago
|
Description
•