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 WinForms ChromiumWebBrowser.RequestContext setter when the assigned value's UnWrap() result is not assignable to CefSharp.Core.RequestContext. As with BrowserSettings, the native bridge requires the exact core concrete type; a custom IRequestContext whose UnWrap() returns something else is rejected. The message names the expected type.

Source

Thrown at CefSharp.WinForms/ChromiumWebBrowser.cs:160

        public bool ActivateBrowserOnCreation { get; set; }
        /// <summary>
        /// Gets or sets the request context.
        /// </summary>
        /// <value>The request context.</value>
        [Browsable(false), DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden), DefaultValue(null)]
        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>
        /// A flag that indicates whether the control is currently loading one or more web pages (true) or not (false).
        /// </summary>
        /// <value><c>true</c> if this instance is loading; otherwise, <c>false</c>.</value>
        /// <remarks>In the WPF control, this property is implemented as a Dependency Property and fully supports data
        /// binding.</remarks>
        [Browsable(false), DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden), DefaultValue(false)]
        public bool IsLoading { get; private set; }
        /// <summary>
        /// The text that will be displayed as a ToolTip
        /// </summary>
        /// <value>The tooltip text.</value>
        [Browsable(false), DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden), DefaultValue(null)]
        public string TooltipText { get; private set; }

View on GitHub (pinned to 16bc6e0711)

Solutions

  1. Use `new CefSharp.Core.RequestContext(...)` (or ObjectFactory-created instance) rather than a custom implementation.
  2. Align all CefSharp.* assembly versions so RequestContextType identity matches.
  3. Call UnWrap() on your reference and verify it is the Core type before assigning.
  4. Pass null for the default context instead of a foreign type.

Example fix

// before
browser.RequestContext = customCtx; // customCtx.UnWrap() is not Core.RequestContext

// 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; mixing CefSharp assembly versions so the Core type identity differs.

Common situations: Unit tests with stub IRequestContext; version-mismatched CefSharp assemblies; wrapping the context in a decorator that does not UnWrap to the core type.

Related errors


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