Search code examples
cefsharpchromium-embeddedwebview2

CefSharp vs WebView2

I'm considering moving a project from cef (CefSharp) to WebView2 WPF. My preliminary tests shows that WebView2 API have the interface I need for this port. I am afraid that I can miss something that can prevent me from switching to WebView2 and I'll figure this out at later stage of this transition. If anyone went through this process, please share if I need to be aware of something that can be a roadblock for this transition. Are there important APIs from cef that are missing in WebView2?

Solution

  • This issue in WebView2's Github answers your question in part. And I would like to add my take.

    A summary:

    • WebView2 doesn't have an API for simulating user input, it's unsuitable for automation.
    • WebView2 can't render offscreen. No running in the console, as a service, on a server.
    • WebView2 runs in a separate process; CefSharp runs in the application's process.
    • WebView2 has a sandbox; CefSharp doesn't.

    This answer is based on my personal experience and is not an exhaustive comparison.

    Process Model

    The Chromium process model has the main process and many auxiliary processes. It is, of course, a bald simplification, but it will do.

    Both CefSharp and WebView2 follow this process model with one very significant difference. CefSharp starts Chromium in the application's process, and WebView2 starts it as a separate process.

    The in-process model is common to all CEF-based browsers. Pros: the browser starts faster. Cons:

    • If CEF crashes, it takes the application down with it.
    • If there's a vulnerability in CEF or Chromium, it can also expose the application's memory.

    The out-of-process model is popular among proprietary browsers. Not only WebView2 works this way, but also DotNetBrowser and EO.WebBrowser. Pros:

    • It's safer.
    • It doesn't bite off the application's RAM. Cons:
    • It starts longer.
    • It may be slower because of inter-process communication.
    • Occasionally, there are issues with the focus and drag-and-drop because the browser window belongs to another process. Not applicable for the offscreen rendering, though.

    CefSharp process model. WebView2 process model.

    A score for WebView2.

    Offscreen Rendering

    There are two approaches to the rendering of embedded web content. One is to shake off the bells and whistles from an actual Chromium window and embed it into the application. We call this "windowed" or "heavyweight" mode. Another approach is to render web content in memory and draw it on an arbitrary surface. It's called "offscreen rendering."

    WebView2 supports only windowed rendering. This mode has two significant drawbacks: it requires a window to function, and the browser always stays on top (aka the airspace issue).

    CefSharp also has offscreen rendering. It allows the application to run in the console, overlay web content with other controls, render web content in Unity3D, etc.

    A score for CefSharp.

    Automation

    The bread and butter of automation is simulating user input. CefSharp has an API for dispatching "real" mouse and keyboard events to the browser. The browser handles these events as user gestures, and JavaScript can't tell between them and real human input. Look at the SendMouse* and SendKey* methods in IBrowserHost.

    There's no such API in WebView2, only workarounds based on Win API.

    A score for CefSharp.

    Sandbox

    By default, all Chromium processes are sandboxed. It makes them more secure. The Chromium team explains the sandbox in great detail here.

    WebView2 and other out-of-process libraries are sandboxed as well.

    CefSharp doesn't support sandboxing and, it seems, never will (#697).

    A score for WebView2.

    See also