Fix Go Back button focus obscured in ConnectedAnimation detail sample

[Harini Malothu (HariniMalothu17)]

Summary

On the ConnectedAnimation page, keyboard focus can be obscured in the "connected animation between a list page and a detail page" sample. The sample is hosted in a fixed-height Frame inside the gallery page's ScrollViewer.

After navigating in from a lower list item, the detail page's Go Back button receives focus but lands outside the page's viewport, so keyboard focus is on a control the user cannot see (MAS 2.4.11 - Focus Not Obscured).

Fix

Call GoBackButton.StartBringIntoView() right after focusing it, so the page-level ScrollViewer scrolls the focused button into view. The displayed sample code snippet is updated to match.

Repro (before fix)

1. Open ConnectedAnimation (most obvious when the window is not full-height).
2. In the list under "A connected animation between a list page and a detail page", focus a lower item with the keyboard and press Enter.
3. On the detail page the Go Back button is focused but scrolled off-screen / not visible.

After the fix, the page scrolls so the focused Go Back button is visible.

Testing

• Built WinUIGallery (Debug/x64) -> 0 errors.
• Verified via UI Automation that, before the fix, the focused Go Back button reports IsOffscreen = True after navigation.

Recording.2026-08-07.151617.mp4

[Godly T.Alias (godlytalias)]

Is this something scroller should do internally when something in it gets focused?

[Harini Malothu (HariniMalothu17)]

Good question. A ScrollViewer does bring the focused element into view automatically, but only when focus moves via keyboard navigation (Tab / arrow keys) - in that case the input system raises the bring-into-view request for you.

Here the Go Back button is focused programmatically in GoBackButton_Loaded (Focus(FocusState.Programmatic)) so a keyboard user can immediately activate it on landing. Programmatic focus does not trigger that automatic scroll, so with the fixed-height frame still scrolled to where the list item was, the button can remain off-screen. The explicit StartBringIntoView() covers that programmatic-focus case.

(If we instead focused it with FocusState.Keyboard, the scroller would handle it on its own - I kept the explicit call so the focus-visual behavior stays unchanged, but happy to switch to keyboard focus if you'd prefer to lean on the built-in behavior.)

[Harini Malothu (HariniMalothu17)]

/azp run

[Abhijeet Jha (iamAbhi-916)]

LGTM