What causes "NotSupportedException" in dotnet/wpf?

Focus the real underlying element instead of the bridge provider (obtain the actual UIElement/AutomationPeer and call Focus()).

dotnet/wpf · info · NotSupportedException

NotSupportedException

Error message

NotSupportedException

What it means

InteropAutomationProvider is a bridge provider representing an already-dispatched/external element; as an IRawElementProviderFragment it does not support being focused. Its explicit SetFocus implementation throws NotSupportedException to signal clients that focus cannot be set through this provider.

Solutions

Focus the real underlying element instead of the bridge provider (obtain the actual UIElement/AutomationPeer and call Focus()).
Have the client check pattern/interface support before calling SetFocus on the fragment node.
Route focus through the element's own automation peer (Peer.SetFocus) rather than the interop provider.
Treat NotSupportedException as 'not focusable via this node' and fall back to keyboard emulation (SendInput).

Example fix

// before
((IRawElementProviderFragment)interopProvider).SetFocus();
// after
var peer = UIElementAutomationPeer.CreatePeerForElement(targetElement);
if (peer != null && peer.IsFocusable())
{
    peer.SetFocus();
}

Defensive patterns

Strategy: type-guard

Validate before calling

if (provider is not ElementProxy) { /* focus the real element instead */ }

Type guard

bool CanSetFocusViaPeer(AutomationPeer peer) => peer != null && peer.IsFocusable();

Try / catch

try
{
    providerFragment.SetFocus();
}
catch (NotSupportedException)
{
    // bridge provider is not focusable; focus the underlying element instead
    targetElement.Focus();
}

Prevention

Focus the real UIElement or its AutomationPeer, not interop bridge providers
Check pattern support (IPattern.IsSupported) before focus operations
Don't walk IRawElementProviderFragment roots expecting focus support on every node
Use keyboard emulation fallback for non-focusable bridge nodes

When it happens

Trigger: A UIA client (or wrapper code) calls SetFocus on the IRawElementProviderFragment interface of an InteropAutomationProvider — e.g. InvokePattern or focus logic that resolves the provider to the bridge fragment and attempts programmatic focus.

Common situations: UIA clients automating hosted/HWND-bridged content and trying to focus the bridge provider instead of the real element; test frameworks calling SetFocus generically on any provider returned from a fragment walk.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

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

Appendix: source

Thrown at src/Microsoft.DotNet.Wpf/src/PresentationCore/MS/internal/Automation/InteropAutomationProvider.cs:88

            return null;
        }

        ///
        Rect IRawElementProviderFragment.BoundingRectangle
        {
            get { return Rect.Empty; }
        }

        ///
        IRawElementProviderSimple [] IRawElementProviderFragment.GetEmbeddedFragmentRoots()
        {
            return null;
        }

        ///        
        void IRawElementProviderFragment.SetFocus()
        {
            throw new NotSupportedException();
        }

        ///
        IRawElementProviderFragmentRoot IRawElementProviderFragment.FragmentRoot
        {
            get { return null; }
        }
        
        #endregion IRawElementProviderFragment

        #region IRawElementProviderFragmentRoot

        ///
        IRawElementProviderFragment IRawElementProviderFragmentRoot.ElementProviderFromPoint( double x, double y )
        {
            return null;
        }

View on GitHub (pinned to 81131a70a4)