It exposes a sufficient API for interaction with the inner web page ( onmessage, addEventListener/removeEventListener, postMessage). While the original purpose of it was to be an HTML5 plugin for IE and Firefox, it actually works as standalone ActiveX control too, so I could wrap it for use with WPF. It also looks like Adobe is giving it some endorsement.

CEF3 uses Chrome multi-process architecture. The project seems to be alive and active, being currently in sync with Chrome v27. This is probably the best option currently available.

Also, it might be an overkill for our project, as off-screen rendering is not something we really depend on.Ĭhromium Embedded Framework (CEF) and. It looks very appropriate, but I don't like the fact the project is not open-source and the full source is not easily available. I've read the answers and done my own research, but I hope to obtain some more feedback from people who have actually used any of the following options in production-quality projects: Similar questions have been asked here previously. As an alternative solution to these problems, we're considering available options for hosting Chromium instead of WebBrowser control in our WPF/C# project based around HTML editing. Internet Explorer-based WPF WebBrowser control suffers from some keyboard and focus issues and memory leak issues. Updated for 2020, I've linked my article where I compare the memory footprints of different approaches to hosting HTML WebView in a basic Windows Desktop application:

Chromium browser engine