What causes "SR.SetFocusFailed" in dotnet/wpf?

Verify IsVisible, IsEnabled and Focusable on the target control before SetFocus

dotnet/wpf · error · InvalidOperationException

SR.SetFocusFailed

Error message

SR.SetFocusFailed

What it means

UIElementAutomationPeer.SetFocusCore calls _owner.Focus() on the owning UIElement and throws InvalidOperationException (SR.SetFocusFailed) when the element cannot take keyboard focus. This is the standard peer used for most WPF controls, so this is the most common path for the UIA Focus pattern failure.

Solutions

Verify IsVisible, IsEnabled and Focusable on the target control before SetFocus
Focus the control directly with control.Focus() and check the bool return
Set focus via FocusManager.SetFocusedElement(focusScope, element)
In UIA clients, catch InvalidOperationException and fall back to selecting the element instead of focusing

Example fix

// before
peer.SetFocus();
// after
if (button.Focusable && button.IsVisible && button.IsEnabled)
{
    button.Focus();
}
else
{
    button.Focusable = true; // then retry focus
    button.Focus();
}

Defensive patterns

Strategy: try-catch

Validate before calling

bool canFocus = control is UIElement u && u.Focusable && u.IsVisible && u.IsEnabled;

Type guard

static bool CanSetFocus(UIElement e) => e is { Focusable: true, IsVisible: true, IsEnabled: true };

Try / catch

try
{
    peer.SetFocus();
}
catch (InvalidOperationException)
{
    FocusManager.SetFocusedElement(FocusManager.GetFocusScope(control), control);
}

Prevention

Mark automatable controls Focusable=true (avoid TextBlock/Panel targets)
Call SetFocus only after the window is loaded and shown
Use control.Focus()'s bool return instead of the peer in in-process code
Handle focus failure gracefully in UIA clients (e.g. use SelectionItemPattern)

When it happens

Trigger: UIA clients or code calling peer.SetFocus() on a control whose UIElement owner fails Focus(): Focusable=false (e.g. TextBlock, panels), control disabled, hidden/collapsed, or not yet loaded in a window.

Common situations: UI automation tests focusing labels or disabled buttons; focusing controls during window construction before the handle exists; screen-reader clients trying to focus decorative elements.

Related errors

AI-assisted analysis of dotnet/wpf@81131a70a4 (2026-09-14). Data as JSON: /api/errors/99930870396e7463. Report an issue: GitHub.

Appendix: source

Thrown at src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/Automation/Peers/UIElementAutomationPeer.cs:517

            // If the source isn't an HwnSource, there's not much we can do, return (double.NaN, double.NaN) point
            if(hwndSource == null)
                return pt;

            Rect rectElement    = new Rect(new Point(0, 0), _owner.RenderSize);
            Rect rectRoot       = PointUtil.ElementToRoot(rectElement, _owner, presentationSource);
            Rect rectClient     = PointUtil.RootToClient(rectRoot, presentationSource);
            Rect rectScreen     = PointUtil.ClientToScreen(rectClient, hwndSource);
            
            pt = new Point(rectScreen.Left + rectScreen.Width * 0.5, rectScreen.Top + rectScreen.Height * 0.5);

            return pt;
        }

        ///
        protected override void SetFocusCore() 
        { 
            if (!_owner.Focus())
                throw new InvalidOperationException(SR.SetFocusFailed);
        }

        private UIElement _owner;
        private SynchronizedInputAdaptor _synchronizedInputPattern;
    }
}

View on GitHub (pinned to 81131a70a4)