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

[adambarlow]

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     |
|                         |
|_________________________|

[kmgallahan]

@shaheedmalik

Perhaps you should more carefully read the issue...

The WinUI WebView element will 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. We plan to publish a proposed API, in the WinUI spec repo. We will update this proposal accordingly with a link at that time. The APIs included in the API spec will be those that we are proposing to place on the WinUI WebView element directly. In the meantime, we welcome feedback on desired APIs and scope.

Unless you are just sharing information.

[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

[martinsuchan]

Back in 2016 when I was developing full featured UWP browser for Windows Mobile I wrote this blog post about missing features in the original WebView. Some of the ideas are a bit dated, most of them are still relevant:
https://www.suchan.cz/2016/04/make-webview-great-again/

My favourite points:
Proper access to Frames
There is no way in the current WebView how to uniquely identify Iframes in a page or how to run custom JavaScript code in target Iframes. This is especially problematic when developer wants to handle right mouse clicks for opening custom context menu or key combos inside the page using custom JavaScript. Invoking custom script is just not possible inside Frames or Iframes.

Proper Popup Window handling
Since Windows 10 the WebView has a method called NewWindowRequested. This method is raised when the page requests new window to be created. This is nice, but once a new window is created, there is no link between the original page and the new popup window in the page DOM and there is no notification when the parent window is requesting window.close() for the popup window.

[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.

[hansmbakker]

Please also refer to #1298 (proposal for access to cookies in WebView)

[shaggygi]

Ability to view PDFs and SharePoint docs (Word, Excel, etc.) by navigating to URL. Printing APIs would be nice, too.

[adambarlow]

@martinsuchan thank you for posting this blog. I'll take some time to go through this.

@michael-hawker given Edge Chromium's planned distribution model the main case I am referencing in this failure mode would be a machine that has not been updated or in an organization that has not yet pushed the update.

Yes, it would work regardless of app model. The Uno angle is a good question. Thanks for adding Jerome.

In terms of WinRT access we are hoping to explore the needed API set with customers and create a plan to support the necessary usage models moving forward.

[vitordelucca]

So a question need to be asked. Would this work on Xbox? And what about IoT?
Most TV apps on Xbox are actually PWA or Webview apps. This seems very basic. If don't come, Xbox will be stuck with EdgeHTML forever?

I currently have an app for Xbox and Windows that uses the normal WebView when clicking on links there, but the perf is not that great, and I would switch instantly. But not having on Xbox would make things complicated.

And what about IoT too? A lot of enterprise apps there are also web based, and currently stuck on EdgeHTML.

In my opinion, would be quite smart to put new edge engine, read, Blink, as a dependency on Store (just like .NET Native, WinUI, etc is there). It shouldn't rely on a Edge install that the user may not have, or might be removed by the user!
What if the user uninstall Edge?

[martinsuchan]

Vitor Gabriel (@vitorgrs) Great question! The new Chromium based WebView2 should be available on Xbox and IoT as well. Ideally the Chromium WebView should be a separate package downloadable in Store, just like it works on Android, where all apps share the same Chrome WebView, that can be updated separately in Google Play.