Remember hadKeyboardEvent across navigations?

[jakearchibald]

1. User pressed "start game" with mouse.
2. Page navigates to game.
3. Game board is focused with JS.

Right now this will show focus styles, because hadKeyboardEvent has reset as part of the navigation.

Should it be stored in session storage?

From a web standards point of view, should this state travel across origins? In the above steps, imagine if the page with the start button was on another origin to the page with the game board.

This would be observable in the new page by looking at computed styles, so it does leak some data about interaction with the other origin.

[robdodson]

I don't have good answers just sharing some of the history here :)

We've wrestled with this issue a fair bit:

• Should :focus-visible match when returning focus or programmatically focusing?  #88
• When window regains focus, focus-ring class should reapplied to the focused element #9
• Focus-ring is visible after switching browser tabs #115

I think there are two parts to the question:

1. What should happen during programmatic focus?
2. Should we store the user's modality across origins?

I think @Justineo's comment addresses the first question: #88 (comment)

It feels like our heuristic could be "good enough" in that it always tries to match on programmatic focus, but it also feels like the focus() method itself should let the developer adjust this behavior.

Regarding the second question, I'm leaning toward not sharing this information across origins because that feels like it gets into a weird user privacy space. That also makes me wonder about #42 where we discuss the option of letting users opt-in to always displaying a focus indicator regardless of modality. I'm wondering if that indicator should be drawn in a way that does not use the underlying style system so folks can't fingerprint it.

[robdodson]

@jakearchibald Have we ever discussed Focus Navigation Start Point?

One of the ideas Alice and I have been discussing is exposing this to developers. Currently in SPAs folks do focus management by setting tabindex=-1 on an element and calling focus on it when it loads. Often they suppress the focus ring because the element they're moving focus to is non-interactive (maybe it's a heading or a div that wraps new page content). This has always felt kind of hacky and so we'd like to expose an API so developers can say "move the focus start point to this element."

The element itself isn't really "focused" but likely a screen reader cursor would move to it, and the next time the user presses Tab they would be navigating inside of this element. If such an API existed, do you think that's what you'd be using in the scenario you describe?

[jakearchibald]

• What should happen during programmatic focus?

The polyfill does a good job here I think. As in, switching on the last device the user used.

• Should we store the user's modality across origins?

Agreed. But what about same-origin? The polyfill doesn't currently store it, hence the issue I ran into, but it could via session storage.

@jakearchibald Have we ever discussed Focus Navigation Start Point?

I hadn't read that before, and it's great, but I don't think it applies in this situation.

In this case, I want to show focus styles if the user used keyboard, but I don't want to show focus styles if the user used mouse. focus-visible generally does a good job with this, unless there's a navigation in the middle. If there's a navigation in the middle, focus-visible forgets that the mouse was used.

Maybe the workaround I used can explain it better than I can GoogleChromeLabs/proxx@bfea7b5.

[jakearchibald]

In fact, here's a reduced demo https://static-misc.glitch.me/focus-visible/.

[robdodson]

@alice do you happen to know if Chromium's focus type flag gets reset when someone navigates?

@jakearchibald I think I'm ok with adding this to session storage—Alice do you have any thoughts?

Jake I don't know if you have the bandwidth to do a PR on the polyfill to add this? If not that's totally OK, I can try to get to it sometime soon.

[jakearchibald]

I'll put it on my backlog

[zerofirework]

I'm running into the same problem with native focus-visible implementation. I'd like to dig out this old thread since Jake was here :D.

In the following example: https://codesandbox.io/s/focus-on-page-load-jy595z?file=/src/index.js, I programmatically focus the span on page load. To my surprise, the span receives focus-visible and shows the focus ring. If I understand correctly, focus-visible is only applied to an element if it is focused from a keyboard interaction. I guess chromium follows similar logic as the polyfill, which sets the keyboard interact status to true by default.

My question is why focus-visible behave in such a way? I'm building a player widget that uses focus-trap library. It automatically focuses an element on page load. This behavior is causing UI issues...