cefsharp/CefSharp · error · Exception

RequestContext can only be of type {0} or null

Error message

RequestContext can only be of type {0} or null

What it means

Thrown by the WPF ChromiumWebBrowser.RequestContext setter when value.UnWrap() is not assignable to CefSharp.Core.RequestContext. The native bridge requires the exact core concrete type; a custom IRequestContext whose UnWrap() returns a different type is rejected. The message names the expected type for clarity. Mirror of the WinForms RequestContext type error.

Source

Thrown at CefSharp.Wpf/ChromiumWebBrowser.cs:234

            }
        }
        /// <summary>
        /// Gets or sets the request context.
        /// </summary>
        /// <value>The request context.</value>
        public IRequestContext RequestContext
        {
            get { return requestContext; }
            set
            {
                if (browserCreated)
                {
                    throw new Exception("Browser has already been created. RequestContext must be " +
                                        "set before the underlying CEF browser is created.");
                }
                if (value != null && !Core.ObjectFactory.RequestContextType.IsAssignableFrom(value.UnWrap().GetType()))
                {
                    throw new Exception(string.Format("RequestContext can only be of type {0} or null", Core.ObjectFactory.RequestContextType));
                }
                requestContext = value;
            }
        }
        /// <summary>
        /// Implement <see cref="IRenderHandler"/> and control how the control is rendered
        /// </summary>
        /// <value>The render Handler.</value>
        public IRenderHandler RenderHandler { get; set; }
        /// <summary>
        /// Implement <see cref="IAccessibilityHandler" /> to handle events related to accessibility.
        /// </summary>
        /// <value>The accessibility handler.</value>
        public IAccessibilityHandler AccessibilityHandler { get; set; }

        /// <summary>
        /// Raised every time <see cref="IRenderWebBrowser.OnPaint"/> is called. You can access the underlying buffer, though it's
        /// preferable to either override <see cref="OnPaint"/> or implement your own <see cref="IRenderHandler"/> as there is no outwardly

View on GitHub (pinned to 16bc6e0711)

Solutions

  1. Use `new CefSharp.Core.RequestContext(...)` rather than a custom implementation.
  2. Align all CefSharp.* assembly versions so RequestContextType identity matches.
  3. Verify value.UnWrap().GetType() is assignable to the Core type before assigning.
  4. Pass null for the default context if you do not need isolation.

Example fix

// before
Browser.RequestContext = customCtx; // UnWrap() is a foreign type

// after
Browser.RequestContext = new RequestContext();
Defensive patterns

Strategy: type-guard

Validate before calling

var rc = new RequestContext();
if (rc.UnWrap() is CefSharp.Core.RequestContext)
{
    browser.RequestContext = rc;
}

Type guard

static bool IsValidRequestContext(IRequestContext value)
    => value == null || value.UnWrap() is CefSharp.Core.RequestContext;

Prevention

When it happens

Trigger: Assigning a custom IRequestContext implementation whose UnWrap() does not return CefSharp.Core.RequestContext; passing a mock/stub; mixing CefSharp assembly versions so the Core type identity differs.

Common situations: Unit tests with stub IRequestContext; version-mismatched CefSharp assemblies; decorator wrappers that do not UnWrap to the core type.

Related errors


AI-assisted analysis of cefsharp/CefSharp@16bc6e0711 (2026-08-13). Data as JSON: /api/errors/e596cfa2b6cc45f8. Report an issue: GitHub.