We have to keep track of whether the selection or focus was set more recently, because if the selection is set and then an ancestor is focused, focus navigation should start from the focused ancestor (but if it happens the other way around, it should start from the selection).

There is a test which fails without this because it's doing some focus navigation while the window is defocused. Which isn't normally possible to do AFAIK but might as well add this check.

I think it maybe makes more sense to do this before running focus event listeners. Otherwise, some tests fail because they call inside the focusin listener which causes unexpected behavior (old starting point is still set).

e.g. the "Backwards focus navigation should not be stuck when starting point is inside focused element but before any other focusable areas" test I added fails without this.

Which test?

I think it's confusing that exists with that name and is labeled with #sequential-focus-navigation-starting-point, but then we're adding a similarly named , as well as having to determine that spec concept. From the spec, would be responsible for tracking the starting point set through a click, while we do this in the method through the selection. But the method also considers the currently focused area, which the spec does in the sequential focus algorithm.

Chrome seems to call at various points like and . Could we also rely only on ? That seems closer to spec.

Should this test / these subtests be tentative?

https://html.spec.whatwg.org/#sequential-focus-navigation-starting-point

setting on click is optional. Or maybe setting is could be made normative.

This one here: https://searchfox.org/firefox-main/rev/e28b34ab33dbf49364999070168cbb7e11e8e5bd/browser/components/aboutlogins/tests/browser/browser_tabKeyNav.js#114
In the last iteration of the loop there, it presses tab while the last element in the DOM is focused, so the window gets defocused (which probably wasn't intentional, so maybe it's worth fixing that test). I think it probably makes sense not to do this when leaving the document anyways, though I don't think it would actually cause any real problems in practice.

Yes I agree that it's confusing, and it would be nicer to handle everything in one place. The only problem is that updating the starting point when an element is removed is a bit expensive, so it would be better not to do that in the more common case where can get it from the focused element or selection instead. Maybe it's clearer if we rename this to .

In fact, the only place it's required to be set is during certain navigations, but all browsers currently set it on click AFAIK. Still, maybe it's best to make this tentative.

Thanks. It's not clear to me yet why this is needed, but I'm also not familiar enough with this.

The test moves focus to the browser, then moves focus backwards. Manually, this works fine with and without this change. Without this, the test succeeds initially, but then gets stuck some back navigations later at an input element. Strange.

Unless there is a reason not to?

So this is the originally focused content, but only if we do . And skip refers to later where .
Maybe add a comment or split it into and some bool?

I'm unsure about this.

Looking at the spec and subtest, the sequential focus navigation starting point is the click position. Direction is backward, selection mechanism should be DOM. Either way I think the spec returns the div, not the button. The focusing steps have an early return and would do nothing. The spec likely gets stuck too, perhaps moving focus counts as "the user indicates that it should be moved". Maybe we should file an issue for that.

Effectively, what I'm wondering is whether we should first show a focus ring around the div before moving focus to the button. Safari does so, but gets stuck on the div. Chrome shows a focus ring on shift and then moves to the button on shift tab.

Yeah, what's happening is that this check here is failing, so is called but not . I suppose we could clear the previously-focused content in instead to fix this, but I don't think that's actually necessary.

Oh yes thanks, I don't know how I missed that method :)

Hmm maybe actually it's fine to always skip the focused content, that would simplify this a bit. I will run it through try though to be sure…

Yeah, probably it's worth filing a spec issue about this: https://github.com/whatwg/html/issues/12514
You're right that we could also solve this by not showing the focus ring until shift+tab is pressed, though we'd also need to set when we do show the focus ring… This way keeps the current behavior, but I could go either way

Probably this check isn't necessary, but with how complicated is, I wouldn't be surprised if there is some strange case where it returns the start content, and it's probably best not to hang if that happens

Nit: maybe check first.

Hmm actually this should compare against , rather than just checking the element state, since shadow hosts have even if it is something inside of it that is focused.

Oh in fact, it does return the starting content in certain cases such as radio groups or having only one focusable element on the page. So probably best to just remove that assertion.