microsoft / microsoft-ui-xaml

Windows UI Library: the latest Windows 10 native controls and Fluent styles for your applications
MIT License
6.35k stars 677 forks source link

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

Open kmelmon opened 4 years ago

kmelmon commented 4 years ago

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

Summary

This came out of root causing https://github.com/microsoft/react-native-windows/issues/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

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 commented 4 years ago

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 commented 3 years ago

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.