Clarify the sequential focusing behaviour when the current focused element is not in the sequential navigation order

[sefeng211]

STR:

• Open https://jsfiddle.net/g68dy7f9/1/
• Click focus the last input
• Press <tab>

Firefox moves the focus to <input tabindex=1 placeholder="a"> and Chrome moves the focus to <input tabindex=0 placeholder="b">.

Which behaviour is correct? Should this fit into the selection mechanism is DOM + direction is forward of https://html.spec.whatwg.org/multipage/interaction.html#sequential-navigation-search-algorithm? What does following starting point mean?

P.S. The specification around sequential focusing is hard to follow

[hsinyi]

@past I'd like to nominate this issue for the next triage meeting #9070

This is blocking against fixing this interop-2023 test case on Gecko. Thank you.

[dizhang168]

This logic is from here:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/page/focus_controller.cc;l=604-611;drc=f9acec33cd12e6a09eefcf7b4de0d357ebf6b5fb
where we are moving from the current element with starting tabindex=-1 and it tries to find the next lowest tabindex that is higher than starting tabindex.

[josepharhar]

It looks like the test was added here: https://chromium.googlesource.com/chromium/src/+/891ceec45f09bcc6664ad1fcb0684e16f7a3d053
Which referenced this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=600621
This patch and bug seem to be about shadowdom, not the minimized test case of interest here. Since that patch doesn't touch the FocusController code that Di mentioned and Safari also has chrome's behavior, we have probably been doing this for a long time. I don't have a justification for it

[sefeng211]

So my investigation of that interop testcase leads to this issue and I think they are related, having this issue clarified can help us to determine the correct fix for that interop testcase.

Here's me trying to break down the spec:

1. I think we start with this algorithm.
2. starting point would be <input tabindex=-1 placeholder="click focus me first">, direction would be forward.
3. In step 4, since this element is not navigable and also not in its Document's sequential focus navigation order (due to negative tabIndex), so the next line applies:
   • starting point is not in its Document's sequential focus navigation order; let selection mechanism be DOM.
4. Then we go to this confusing chart to the pick the sequential-navigation-search-algorithm
5. If selection is DOM and direction is forward, we should use this algorithm:
   • Let candidate be the first suitable sequentially focusable area in the home document following starting point, if any; or else null

The confusing part is what does following starting point mean? starting point is not a suitable-sequentially-focusable-area right?

I know the behaviour is consistent between Chrome and Safari, so I am not too confident about my breakdown, However I am also not sure what I am missing.

[domenic]

I think your breakdown is correct.

The confusing part is what does following starting point mean? starting point is not a suitable-sequentially-focusable-area right?

I am 80% sure the intention here is to use DOM tree order. (Unclear on the intended behavior when there are shadow trees...) Because we are in the DOM case. The result is null, then: there is no element at all following starting point in the DOM.

So I think continuing on with the calling algorithm, we should unfocus the starting point and focus the browser UI (step 8). Which is not what any browsers do? But does seem logical to me... Hmm.

If we decide to stick with the current spec, we should definitely clarity it to use well-defined terms like tree order. (Shadow-including tree order?) And in general there's some ways we could improve clarity in these algorithms. But I'll hold off on that until we have a consensus on the desired algorithm...

[sefeng211]

cc @smaug---- @emilio

[sefeng211]

I think we prefer DOM tree order that makes the most intuitive sense. So it should focus first element in DOM tree order for this example which is <input tabindex=1 placeholder="a">.

[domenic]

DOM tree order makes sense, but the point is that once you reach the end of DOM tree order when tabbing, you need to focus browser UI, per step 8. (This is normally how tab-focusing works.) So I don't think we should skip that and wrap back around to the placeholder=a element.

[zcorpan]

I think Firefox's behavior makes the most sense and is what I'd expect as a user. The DOM position of the tabindex=-1 element doesn't matter since it's not in the tab sequence. For example, if the user clicks somewhere on a page and happens to click on a focusable tabindex=-1 element, and then press tab, they probably want to interact with the page rather than the browser UI.

[domenic]

I think that depends, doesn't it? If they click somewhere near the top of the page, then press tab, they probably want to focus the next sequential-focusable one after that click point, i.e. something close by, probably still near the top. But if they click somewhere near the bottom of the page, then pressing tab to focus the browser UI makes sense, since the browser UI is always "between" the bottom of the page and the top of the page in the tab cycle.

[smaug----]

@annevk do you have an opinion on this?

[annevk]

What @domenic suggests makes sense to me. There's no reason for focus to go backwards and we don't have a special "don't go via browser UI" heuristic (although browsers are allowed to offer that of course).

(Unfortunately the clicking doesn't work as expected, e.g., if I click between the controls on data:text/html,<p><input><p><input> the first one seems to always get focused afterwards. But that's a general thing some browsers have, search-in-page also frequently goes from the top despite that not always being the most useful behavior.)

cc @rniwa

[mfreed7]

I agree with what @domenic suggests also. From a user's perspective, if they click near the bottom of the document, the focus should move to something after (below) that point. If there are no further tab stops, the expectation would be that it "wraps around" to the browser UI.

(What's really unfortunate is that users likely also expect this when clicking in the <body> but at a pixel location below any DOM content. In that case, it'd also make sense to go to the browser UI. But the focus traversal doesn't (and likely can't) take that into account.)

[mfreed7]

(I also agree that this is what the spec seems to currently say, but unfortunately not what browsers do. However, I'm in favor of trying to align browsers with the spec, if that's possible.)