fix(controls): Fix ContentDialog interaction, focus, and modal behavior issues

[apachezy]

Pull request type

Please check the type of change your PR introduces:

• Update
• Bugfix
• Feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Documentation content changes

What is the current behavior?

ContentDialog is intended to behave as a modal dialog, providing consistent interaction, predictable focus handling, and proper isolation from the host window.
However, in its current implementation, several interaction, robustness, and accessibility issues can be observed under common usage scenarios—especially when keyboard navigation, access keys, dialog chaining, and automation tools are involved.

• Interaction & Robustness Issues

  • When both ContentDialog and the host window have default/cancel buttons, incorrect key responses may be triggered

  • Host window access keys (e.g., &Execute/_Execute buttons) and shortcuts can still be activated while the dialog is open

  • Initial focus logic does not follow Windows App design guidelines, violating user interaction habits

  • Keyboard operations cannot be performed when only a close button is present

  • Pressing Ctrl + Tab or (Up/Down/Left/Right) can move the focus out of the dialog

  • The focus will not return to its original position after the ContentDialog is closed

  • Opening a new ContentDialog before the previous one is closed causes task hanging—the ShowAsync method never returns.
    Typical scenario: Navigation between dialogs.

• UI Automation/Accessibility Issues

  • Assistive tools can move keyboard focus outside the dialog boundaries

  • ContentDialog lacks proper modal dialog characteristics for automation

Issue Number: #1585, #1618

What is the new behavior?

This PR introduces a new ContentDialogHost and refines the behavior, accessibility, and reliability of ContentDialog, while preserving backward compatibility.

• Added ContentDialogHost. While a dialog is shown, the host layer intercepts access key events and preview command events, clears the host window’s InputBindings and CommandBindings to block various input interaction paths, and restores them when the dialog is closed.

  The newly introduced ContentDialogHost is not only intended to address the existing issues, but also to overcome structural limitations of ContentDialog itself, providing a foundation for future extensibility.

  For example, it enables scenarios such as a truly interceptable Closing event, cross entrance/exit animations, and dialog stacking.

• ContentDialogHost now stores the focused element before the dialog is shown and attempts to restore focus after the dialog is closed.

• Kept support for the legacy host (ContentPresenter). Existing code continues to work without changes, but compiling with the legacy host will emit deprecation warnings.

• Introduced ContentDialogHostController to maintain compatibility and allow unified handling of events for both host types.

• Added DisableSiblingsEnable to ContentDialogHost for high-safety scenarios. When enabled, sibling elements of the host are disabled while the dialog is displayed. For the legacy host (ContentPresenter), this can be enabled via the attached property ContentDialogHostBehavior.DisableSiblingsEnable="True".

• Refactored ContentDialog focus logic into partial classes. The initial focus behavior is now aligned with WinUI and avoids focusing “destructive / warning” buttons by default, in accordance with the Windows App Design Guidelines.

• Updated the ContentDialog style to include KeyboardNavigation.ControlTabNavigation = Cycle. Pressing Ctrl+Tab no longer allows focus to escape the dialog. With a defined initial focus, directional navigation also remains within the dialog. If developers override the ContentDialog template, they must explicitly set KeyboardNavigation.TabNavigation, KeyboardNavigation.DirectionalNavigation, and KeyboardNavigation.ControlTabNavigation.

• Added ContentDialogAutomationPeer so that automation and accessibility tools recognize ContentDialog as a modal dialog.

• Fixed an issue where opening a new ContentDialog before the previous one was closed could cause ShowAsync to hang.

Below are some demonstration videos illustrating the behavior after the fixes have been applied.

• Initial focus is never placed on dangerous buttons (ControlAppearance = Danger/Caution):

ContentDialog-SafeInitialFocus.mp4

• UI Automation behavior aligns with WinUI 3:(Enable audio to hear screen reader)

ContentDialog-UIAutomation.mp4

• The UIAutomation tool will not bring focus out of the dialog box:

ContentDialog-AutomationContainment.mp4

Other information

• Since all issues originate from ContentDialog, submitting separate PRs for each fix would be inefficient. Additionally, the fixes are interrelated and prone to conflicts. Therefore, they are addressed comprehensively in this single PR.

• Fixed Close button of simple ContentDialog does not react to Enter key #1585

• Fixed [Critical] ContentDialog causes memory leaks when ShowAsync task hangs #1618

[apachezy]

This solution is still not mature. If the ContentDialog does not contain focusable controls, assistive tools will keep focus on the host window, and the UI automation suppression cannot take effect. I am closing this PR again until a stable method is identified.

[luca-domenichini]

That's really unfortunate.
The current WPF-UI implementation without this PR merged, infact suffers from focusing problems. This PR would be very valuable.
Will you still try to find a better solution?

[apachezy]

The issue appears to be resolved. I'm reopening this PR.

[apachezy]

Implementation is feature-complete. Cleanup tasks are deferred until the associated bug fix PR (#1615) is reviewed/merged.

[apachezy]

I have consolidated the history into a single, clear commit for easier review. All changes are included.