Proposal: A WebView based on Microsoft Edge (Chromium) in WinUI 3

Proposal: A WebView based on Microsoft Edge (Chromium) in WinUI 3

Summary

The Microsoft Edge browser is moving to be based on the Chromium web engine. This proposal is to create a WebView in WinUI 3 which takes advantage of the Microsoft Edge Webview2. This will allow WinUI 3 apps to host web content in the most relevant and standards compliant way.

We have now released a preview of the control in WinUI 3.0 Alpha (February 2020) 🚀👩‍💻🎉

Rationale

• The latest version of Microsoft Edge will be using Chromium and the current XAML WebView is based on the EdgeHTML engine
• WinUI developers would have access to the web-compatible Chromium platform
• The performance characteristics of web content in WinUI apps will begin to match that of Chromium
• WinUI app developers have requested this feature

Scope

Capability	Priority
Developers can host standards-based web content rendered by the Chromium engine in WinUI apps	Must
Support the Microsoft Edge ‘evergreen’ update model, keeping the WebView rendering up to date with the latest auto-update of Microsoft Edge on the users system	Must
Released as an open source component in the WinUI repo	Should
Developers can host web content in apps on all OS releases where WinUI 3 is supported	Should
Gracious failure when WebView is run without Microsoft Edge (Chromium) installed	Should
Smooth migration experience for current users of EdgeHTML Webview	Should
Allow simple access to WinRT APIs via AddWebAllowedObject	Should
Access to WinRT directly via JavaScript	Could (not in v1)
Ability to package a specific version of Microsoft Edge with the app, e.g. BYOV	Could (not in v1)

Proposed API

The WinUI WebView element will be built on top of the Microsoft Edge WebView2 API. We have yet to determine the full shape and set of APIs for the WebView element. A draft spec for the WebView2 has been posted to the spec repository.

APIs included in the API spec are those being proposed for the WinUI WebView element directly. Additional APIs will reside on the WebView2 core object. There are not represented in the API spec linked above.

In short; If you don’t see an API in the WebView2 API spec and it is existing functionality of the current WebView, it is likely planned to be included on the base WinRT object, whose API is likely to closely match the current IWebView2WebView interface.

The high-level API structure is pictured below.

 _________________________
|                         |
|       WinUI 3 App       |
|_________________________|
|                         |
| WinUI WebView element   |
|          API            |
|_________________________|
|                         |
|   WebView2 core API     |
|                         |
|_________________________|

[moshegutman]

Please add printing, and print-to-PDF APIs. This is super useful when generating reports based on HTML. The current print options in UWP are terrible. WebViewBrush is not vector based.

https://stackoverflow.com/questions/39012591/uwp-print-webview

[michael-hawker]

I know important features that came late (or didn’t come to the original WebView) are:

• Intercepting each resource request (e.g. being able to add custom headers for auth, serve content from a cache, or filter out bad actors)
• Independently controlling each WebView’s cache, be it sharing from a central cache, or independent from others so that it can be wiped separately from entire app.
• Access to DOM

Am a bit concerned about the fact that if the WebView is a major component of an app and the user doesn’t have the new Edge installed, that the app wouldn’t work without more user involvement. Can there be a base install version of the Edge components that can be installed as a dependency? But just doesn’t show the icon on the user’s start menu in this scenario as in normal install. i.e. still be the evergreen model and not BYOV, but at least do the base install when it’s needed by an app using the new WebView at package/install time (if needed), and not involve extra manual user steps. If the user later installs new Edge, this ‘base’ package all gets replaced by the main bits and WebView is none the wiser.

Also, assuming as part of WinUI 3 it will work regardless of app model? And having it also be able to work when deploying via UnoPlatform would be great too. 😋 FYI @jeromelaban

Can you clarify the AddWebAllowedObject, assuming you mean that a WinRT API can just be dangled off some class the developer creates and call that? But the custom object from the developer (outside of any WinRT APIs) is important too. That’s also the WebView -> App bridge, but there’s no mention of the App -> WebView bridge about being able to call JavaScript on the WebView instance.