1738777 - Tabbing order is incorrect when crossing a shadow root and manually calling focus

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Elliot Nahman]

Attachment: codepen example with tab stops.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.54 Safari/537.36

Steps to reproduce:

In a layout using web components with Shadow DOM, one can tab to different items each living in their own shadow tree. However, manually calling focus on one item then resets the tabbing order to the start of the parent DOM tree instead of continuing on to the next tabbable item in the DOM.

See CodePen for example: https://codepen.io/nonmetalhail/pen/OJjjzej

In my CodePen example, there is a web component comprised of a button in a shadow root. When there are several on a page, you can hit Tab to go to the first button. Hitting Tab again takes you to a DIV with a tabindex and that DIV calls focus on the next web component button. Hitting Tab from the second button takes you back to the first button instead of the third button which is the next item in the DOM.

In the attached image, you see that FF appears to be calculating the correct overall tabbing order, 22 -> 23 ->24, but manually calling focus on the button resets it, causing it to go from 22 -> 23 -> (manual focus call) -> 22.

Chrome and Safari both move focus onto the next item in the DOM rather than reseting to the start.

Actual results:

After manually calling focus on something inside its own shadow tree, hitting Tab brings focus to the first item in the parent DOM tree.

In the example: 22 -> 23 -> (manual focus call) -> 22

Expected results:

After manually calling focus on something inside its own shadow tree, hitting Tab should brings focus to the next tabbable item in the parent DOM tree.

22 -> 23 -> (manual focus call) -> 24

Comment 1

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Sean, I wonder if you have ideas of where our code may do something wrong. And would be interested in knowing if you have a different view on the severity. Thanks!

Comment 2

[Sean Feng [:sefeng211]]

I think this happens when we couldn't find a focusable element in the shadow dom, we update the tabIndex and to continue the search from the top level shadow host. In this case, the tabIndex becomes -1, however I think we should start to ignore tabIndex to do further searches when it becomes -1, but we don't.

I'll make a patch to demonstrate the idea.

Comment 3

[Sean Feng [:sefeng211]]

Attachment: Bug 1738777 - Check whether we need to ignore tabindex again when doing sequential navigation r=smaug

Comment 4

[Sean Feng [:sefeng211]]

Clearing my NI since I have the patch up.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ca57cb620eb3
Check whether we need to ignore tabindex again when doing sequential navigation r=edgar

Comment 6

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/33470 for changes under testing/web-platform/tests

Comment 7

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/ca57cb620eb3

Comment 8

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 9

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Reproduced the issue on Firefox 95.0a1 (2021-06-10) under macOS 11.6.5 by using the STR from Comment 0.

The third item is now selected by tabbing on Firefox 100.0 and 101.0a1. Tests were performed on macOS 11.6.5, Ubuntu 20.04 and Windows 11.