Get started with Microsoft’s new Chromium WebView control

Microsoft’s switch to a new Chromium-based version of Edge is well underway. The company has been offering Edge Insiders access to weekly Developer and daily Canary builds of the new browser for several months, and recently unveiled a more stable beta channel build, updated every six weeks, aimed primarily at end-users. It’s a well-though-out approach that signals a stable release sometime at the end of 2019 or the beginning of 2020.

Changing out your application’s browser controls

The change is significant in many ways: most importantly a separation of browser and operating system. That link between the two had allowed the original EdgeHTML-powered version of Edge to slip behind its competitors, as it could only get significant updates twice a year, with Windows’ updates. Edge was perhaps not at the cutting edge of web technologies, but it was a stable platform for application developers, especially anyone using Universal Windows Platform’s (UWP) embedded HTML WebView controls in their apps.

A Chromium-based Edge doesn’t signal the end of life for those UWP EdgeHTML controls, but it does mean that they’re now in maintenance mode. They won’t get new features and will quickly lag the capabilities of the new Edge browser and any advances in web standards. As part of the transition to a new browser engine Microsoft announced that it would release a new set of WebView controls based on its new browser rendering engine, and that it would allow you to choose how your applications would use the browser control.

Introducing the WebView2 SDK Preview

A preview of the new WebView control launched earlier this summer, with a new SDK. Currently only available for Win32 C++ APIs on Windows 10, it’s the first release of a family of controls and SDKs that will eventually support every version of Windows from Windows 7 on (and for Windows Server from Windows Server 2012 R2). When released, it’s intended to support all the popular Windows application development platforms, with UWP, WinForms, and WPF versions due.

One big change with the new controls is how they’re delivered. There will be two options: an always up-to-date version that updates with the browser so that your users will always have the latest (and most secure) version of the control, even without shipping an application update. The second option is a bring-your-own-version control that’s packaged with an application and runs only on your application’s context, allowing you to ensure your app and its controls are a single, tested package.

Currently the only version shipping is the evergreen, always-up-to-date SDK. It’s a complete Chromium package, with support for status bars and for the Chromium devtools. They all can be disabled in shipping code, but can give you useful information during development. New versions will be released initially every six weeks or so, with the control available through NuGet. The SDK APIs and features are still under development, so new releases do currently require a recompile, though once Microsoft has stabilized the API surface that should no longer be necessary.

As I write, there have been three preview releases of the SDK, with the latest 0.8.230 based on Edge 77.0.230.00 or later. Recent releases have added support for .Net projects as well as APIs to shut down network operations and navigation. Previous releases gave you control over navigation history, HTTP headers, and let you run 32-bit controls on 64-bit Windows.

Building your first WebView2 application

Before you start, install a developer release of the Chromium-based Edge as well as the WebView2 SDK on any development PCs. Once you’ve set up Visual Studio to build C++ Windows apps, download the SDK via NuGet. Downloading and installing it from the repository adds most of the files needed for your app in your solution directory. To use it, include the appropriate header files in your application. If you’ve already installed it, it’s worth checking for an updated release.

Adding a WebView2 control to your code is easy enough. First set up your WebView2 environment. If you select the defaults, the control will use the current installed Edge browser. Alternatively, you can define key browser settings, for example giving your app its own user folder and setting specific browser flags. Once the environment is set up, call CreateWebView to add your WebView2 control, setting the control’s navigate property to the URL your application is using. You can keep track of loading content using NavigationCompleted events.

If your code needs to interact with the contents of an HTML document loaded by the WebView2 control you can inject JavaScript into a page. Messages can be sent to HTML content using postMessage events, which can be trapped via event handlers running in the host application or in the web content JavaScript.

Much of what you need to know to build WebView2 into your application can be found in the SDK’s API reference and more specifically in the IWebView2WebView interface. This is where you will find the settings for the current WebView, as well as controls to work with HTML and JavaScript content. There’s a lot here, so Microsoft has produced a useful example in the shape of a basic web browser, so you can see how code interacts with the contents of a WebView2 window and how to use it in your applications.

Keeping up with the WebView2 browser control

One useful feature in the SDK is the ability to target different Edge channels. By the time it ships, the Chromium-powered Edge will be available in four different versions, shipping on different schedules and with different levels of stability. You will be able to control which version is used, choosing either the most or least stable version, or enforcing a channel via a Windows registry key. This approach gives you the option of testing on developer releases and shipping on production, making sure your code is ready for changes to the underlying browser engine whenever they release.

With Microsoft putting its weight behind WebView2, it’s time to start looking at how you might use it in your code. You’ve still got a few months before the control ships—more than enough time to see how your code needs to change and to build and test prototypes. It’s worth considering how applications you’ve written that use Microsoft’s existing HTML5 APIs, like those used to deliver Office Store apps, need to change to support its feature set as the Edge team is working to have Office’s add-in platform updated to use WebView2.

Mixing the web and local code makes sense, if only to render HTML-based user interface components in your applications. The switch away from semiannual browser updates is significant, and something you need to consider when building hybrid applications that use WebView2, along with how your users install browsers and how they keep them updated. With Edge adopting Chrome’s automatic update model, you’re no longer able to be sure what users have installed and when they’ll update. Getting started with WebView2 now will allow you to develop the most flexible approach to browser compatibility in your code, whether it’s by limiting the HTML and JavaScript you use or by prescribing a specific browser version along with each new release of your code.