Proposal: Add tracing/tooling to aid in tracking focus state changes

[kmelmon]

Proposal: Add tracing/tooling to aid in tracking focus state changes

Summary

This came out of root causing microsoft/react-native-windows#6181
To debug this issue, I had to manually debug through FocusManager code, which is very time consuming and requires deep knowledge of the focus code. There are many scenarios (eg TabFocusNavigation behavior, apps changing focus in the middle of getting focus, etc), and no tooling to make the debugging process easier.

I am proposing adding tracing or other tooling to shed light on the process FocusManager goes through when focus is being changed. This tooling would shed light on why a given control is being given focus, thus making it easier to understand what factors influenced the algorithm, allowing customers to fix or workaround problems where focus is not working as expected.

Rationale

• Customers can unblock themselves when encountering issues
• Time saver for the dev team

Scope

Capability	Priority
This proposal will allow developers to more easily understand why a given control is receiving focus without debugging FocusManager code	Must

Important Notes

Open Questions

[ranjeshj]

Sounds like a great idea. The two tools I have found useful in the past are to put breakpoints in the framework code and adding a page level FocusChanged event to trace out who got focus.

[Austin-Lamb]

Lack of visibility into focus's more complex cases has been a sore point for many users, I agree this is a good feature proposal to have on the backlog.

As a mitigation, one thing that exists now is a set of static events on FocusManager which can tell you about any focus change occurring on the thread - even if they're in unparented popups, where you wouldn't have a good place to listen to a bubbling focus event from UIElement.

Each of these static events has an EventArgs that has a 'CorrelationId' property which is a GUID. This ID is uniquely created when a focus movement operation begins - then as focus meanders through various controls, maybe being redirected as it goes, this ID remains constant so you can tie all the events together in your own logging/debugging. Then, when focus terminates in a new place, that ID is discarded and the next time focus moves we'll create another GUID.

So, that can be one helpful way to debug focus, though it's not great or easy. But at least it's something while this remains on the backlog.