feature to log history of focus changes

[moizgh]

One of the biggest frustrations for me is figuring out what keeps stealing focus all the time! :)

It would be great if there is a devtools feature that can enable capturing a history of focus transition in the DOM. Knowing the sequences of transition would make it so much easier to pin-point the source code / event handler / relevant components to investigate. Usually, figuring out which event handler to set the breakpoint in is the most time-consuming activity and a feature like this may make things a lot quicker.

AB#39079675

[captainbrosset]

Thanks for sharing with us @moizgh!

Here are couple of ideas that might help in this case:

1. Using a snippet to log focus/blur events as they happen on the page:

   1. Create a snippet (in the Sources panel, left sidebar, select the Snippets tab)
   2. Click New snippet.
   3. Enter the following code:

      addEventListener('focusin', e => {
          console.log('Focusing element:', document.activeElement);
      });
      addEventListener('focusout', e => {
          console.log('Blurring, new active element:', document.activeElement);
      });

   4. Save the snippet (Ctrl+S) so it persists in DevTools. You can even give it a name.
   5. Now, whenever you need to log the focus information, execute the snippet (Ctrl+Enter) and open the Console.

2. Another idea would be to use the Live expressions feature in the Console. Here is how to do this: https://devtoolstips.org/tips/en/track-focused-element/

Does this help? I like the idea of tracking history so you can go back later and jump into the code. But I'm wondering if these 2 tips are enough already?

[taurheim]

I've used the above before to track focus, and while it does help to show /what/ has focus, it is still quite difficult to determine /why/ something has focus (in some cases like with a FocusTrapZone, or if there is an iframe in the middle of content focus can get passed around quite a bit). Focus is often very important for keeping content accessible so having a tool like this would be great to help debug more complex focus issues!

[captainbrosset]

So capturing the event handler that caused focus to go somewhere would be helpful, right?

[taurheim]

Yeah, the ideal (not sure how much work this would be) would be:

• Easy way to highlight/track the currently focused element (live expressions work pretty well for this but doesn't work within iframes, you have to switch console context into the iframe when the focus goes inside)
• History of which elements had focus, which handlers led the focus there (bonus points for an easy integration to set breakpoints in them)

[captainbrosset]

Interesting idea related to this. It doesn't solve the problem, but is a good simple step in the right direction: https://twitter.com/jpzwarte/status/1514890537198837761

Why don’t we have a “focus” badge yet in the devtools so it’s easier to see which element has focus? Seems like a no-brainer? (Especially when you only “show” focus with :focus-visible)

[jpzwarte]

@captainbrosset I've used the live expression trick, but it doesn't work x-browser (Safari at least). And it's something you have to do manually (as opposed to a "focus" badge). Also when working with web components, you can't do document.activeElement, but you have to do shadowRoot.activeElement, so it's more cumbersome.
I often find myself wanting to know which element has focus when working on web components and a11y. So a simple badge would really help me in my daily work. Also because the web component often delegates focus to an element inside the shadow DOM.

[captainbrosset]

Very good points! Thank you Jeroen for joining in on the discussion.

From what I heard so far:

• Tracking focus isn't always straightforward, especially when iframes and web components are involved.
• Debugging focus cycle issues is important and, for this, tracking which elements got focused, and why, over time is useful.