Closed duhrer closed 9 months ago
It looks like there are focus
and blur
events on the window
itself. This would be a good opportunity to make the behaviour consistent when switching between keyboard and mouse as well.
It would also let us revert a lot of the changes from #161 that required a dedicated focus function.
The window
focus
and blur
events only fire when the whole window is first focused or blurred.
Thanks to this page, it seems like I found an approach that does work. I created this CodePen to demonstrate, I was able to confirm that:
focusin
is triggered on the window when a new element receives focus.focusout
is triggered when the previous element loses focus.focusout
on the old element and then focusin
on the new.This should let me do what I had in mind. If we have the focus overlay listen for the changes, we don't even need to pass around model variables to track what the overlay should focus on, it can just adjust itself immediately.
Turns out that shadow elements do not report their focusin
and focusout
events back to the window, so you need to add a listener to the shadow elements you care about (in our case, only the modal manager's shadow element). Once that was done, this works pretty well.
In looking into the first item, I noticed that the onscreen keyboard uses its own focus management, which directly calls focus on the individual keys. I'll have to read up and see if there is some more general way of tracking focus changes and see if we can listen to that. Another thought is to add a model listener for focused row and column changes and update
focusOverlayElement
manually.If we can figure out why the optional indicator sometimes works when wrapping, then we might be able to use that approach elsewhere.