Editable ComboBox with Fluent theme is a keyboard trap: Shift+Tab does not move focus to the previous control

[wnvko-msft]

Description

When using the .NET Fluent theme (PresentationFramework.Fluent), an editable ComboBox (IsEditable="True") traps keyboard focus. With focus in the ComboBox edit field, pressing Shift+Tab does not move focus to the previous control. Forward Tab works, but Shift+Tab does not, so keyboard-only users cannot navigate backward out of the control.

This is a regression/inconsistency versus the classic (Aero2) theme, where the same editable ComboBox lets Shift+Tab move focus correctly.

Reproduction Steps

1. Create a WPF app targeting net10.0-windows and apply the Fluent theme by merging pack://application:,,,/PresentationFramework.Fluent;component/Themes/Fluent.xaml in App.xaml.
2. Add a window with three focusable controls in tab order: a Button, an editable ComboBox, and another Button:

<StackPanel>
    <Button Content="Before" />
    <ComboBox IsEditable="True" SelectedIndex="0" MinWidth="200">
        <ComboBoxItem Content="8" />
        <ComboBoxItem Content="10" />
        <ComboBoxItem Content="12" />
    </ComboBox>
    <Button Content="After" />
</StackPanel>

3. Run the app. Click/Tab into the editable ComboBox's edit field.
4. Press Shift+Tab.

Also reproducible in the WPF Gallery sample: Basic Input -> ComboBox -> "An editable ComboBox" example.

Expected behavior

Pressing Shift+Tab from the editable ComboBox edit field moves keyboard focus to the previous control (the "Before" button), matching forward Tab behavior and the classic theme.

Actual behavior

Pressing Shift+Tab does not move focus out of the ComboBox. Focus remains trapped in the ComboBox edit field, so the user cannot navigate to the previous control using the keyboard.

Regression?

Yes, relative to the classic (Aero2) theme. The classic theme's editable ComboBox handles Shift+Tab correctly; the Fluent theme does not. Both use the same ComboBox class, so the difference is in the Fluent theme's ComboBox style/template.

Known Workarounds

Set IsTabStop="False" on the editable ComboBox so only its inner edit field remains a tab stop:

<ComboBox IsEditable="True" IsTabStop="False" ... />

This mirrors what the classic theme does automatically and restores correct Shift+Tab navigation.

Impact

Accessibility keyboard trap. Motor-impaired and keyboard-only users cannot navigate backward past an editable ComboBox, violating WCAG 2.1.1 (Keyboard) / MAS 2.1.1. Affects every editable ComboBox in any app using the Fluent theme.

Configuration

• .NET version: .NET 10 (net10.0-windows), Microsoft.WindowsDesktop.App 10.0.9
• OS: Windows 11 (24H2 / 25H2)
• Architecture: x64 (not architecture-specific)
• Specific to the Fluent theme (PresentationFramework.Fluent); does not repro with the classic theme.

Other information

Root cause appears to be in the Fluent theme's DefaultComboBoxStyle. Its IsEditable="True" trigger only swaps the control template and does not set IsTabStop="False" on the ComboBox:

src/Microsoft.DotNet.Wpf/src/Themes/PresentationFramework.Fluent/Styles/ComboBox.xaml

<Trigger Property="IsEditable" Value="True">
    <Setter Property="Template" Value="{StaticResource EditableComboBoxTemplate}" />
</Trigger>

The classic theme sets  IsTabStop="false" in the equivalent trigger:
src/Microsoft.DotNet.Wpf/src/Themes/XAML/ComboBox.xaml

<Setter Property="IsTabStop" Value="false"/>

As a result, under Fluent both the ComboBox itself and its inner PART_EditableTextBox are tab stops; Shift+Tab lands on the ComboBox container, which redirects focus back into the edit field, causing the trap. Adding <Setter Property="IsTabStop" Value="False" /> to the Fluent IsEditable trigger should resolve it, matching the classic theme.