XYFocus cannot easily be restricted to branches of the visual tree. about avalonia

[IanRawley]

One more idea for me actually, implement ICustomKeyboardNavigation somewhere appropriate and use that to trap XYFocus within a tree.

EDIT: Won't work. None of the XYFocus methods that would be needed are public. They're all internal / private.

[IanRawley]

https://learn.microsoft.com/en-us/windows/apps/design/input/focus-navigation#enabled

Looks like UWP behavior is supposed to prevent XY navigation between 2 sibling XYFocusKeyboardNavigation="Enabled" subtrees if their parent is explicitly disabled. See the second image in the linked section.

I'm not sure I think that's the right way to do it. Personally I feel having more explicit control over boundaries without having to disable XYFocus is the better way.

If desired though I could probably do a PR to implement UWP behaviour here as well.

[IanRawley]

Digging into WinUI 3 code it behaves the same way, bubbling an XY navigation event up from the source until it finds a candidate to focus or hits a parent that isn't XY navigation enabled. See
https://github.com/microsoft/microsoft-ui-xaml/blob/66a7b0ae71c19f89c6a7d86a1986794ad1a1bf09/src/dxaml/xcp/core/dll/eventmgr.cpp#L1385C9-L1401C6

and here
https://github.com/microsoft/microsoft-ui-xaml/blob/66a7b0ae71c19f89c6a7d86a1986794ad1a1bf09/src/dxaml/xcp/components/focus/inc/FocusSelection.h#L77-L80

[IanRawley]

I've started work on a PR to implement WinUI / UWP style subtree restrictions, and hit a snag with the XYFocus helpers.
@maxkatz6 did the original PR, so maybe you have some input.

private static bool IsAllowedXYNavigationMode(XYFocusNavigationModes modes, KeyDeviceType? keyDeviceType)
{
    return keyDeviceType switch
    {
        null => true, // programmatic input, allow any subtree.

This always allows XYNavigation, even if the mode is XYFocusNavigationModes.Disabled, if the keyDeviceType is null. Which it is during all the Unit Tests using KeyboardNavigationHandler.GetNext(...) for Assert checks. So while all the Unit Tests set XYFocusNavigationModes.Enabled to the Window used, very few actually respect it intentionally. Is that really intended behaviour, or should the null case instead be true if modes != Disabled?