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]

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

[adambarlow]

Working on all OS versions where WinUI 3 is supported is certainly a goal, as called out in the scoping section. We will be able to get more specific moving forward about supported endpoints for the v1, but we really love getting this feedback. The user removing the Edge browser will not be an issue as the APIs necessary for the WebView will be available as part of an OS update.

[fitojb]

These days, nearly every single Desktop app has an HTML view in some form

This isn’t something to be proud of at all. <⁠/offtopic>

[noseratio]

@fitojb

This isn’t something to be proud of at all.

I know, but that's the reality. You might be surprised at how many Microsoft's own projects use Chromium in some form. To check it out, go to https://thirdpartysource.microsoft.com and type in Chromium in the Filter field.

[jschroedl]

Based on APIs we wish we had in our WPF usage of WebBrowser, I hope that we have client APIs for the following:

• API to manage cookies. I recall lots of pain and hoops to clear cookies for a given site/domain.
• Airspace issues - Since it should use WinUI that may no longer be a problem, right?
• Save of rendered page to a file. We have many automated tests where our client app generates a report as HTML and our internal scripting system would greatly benefit from the ability to load a page into the control and save the rendering to file for our CI image diffing tools.
• Printing APIs.
• APIs so that we can participate in authentication. Don't want to do the IOleClientSite, IAuthentication dance. Imagine I want to have a window/dialog containing a WebView2 so that I can use it to authenticate/login to a service. I would like events informing me of the various redirects and auth request responses for UI and auditing purposes.
• API to suppress script errors
• Ability to open links in the user's default browser (WebView2 showing some help content for example with 'more info' links opening the default browser. Had to go through IDocHostUIHandler in the past.
• API to enter a silent/kiosk mode where there will not be pop-ups or other debug messages shown.

[kitgrose]

I'm glad to hear there's a plan to get the new browser engine into apps. The existing UWP WebView control was a pain to use for us in a couple of ways, and I would love to see them considered in the design of the newer control:

1. The current WebView control hosts content on the UI thread by default on desktop, and there's no declarative way of setting WebViewExecutionMode in the XAML, which means if we want our app to remain responsive while the browser is loading, we can't use the WebView directly in our XAML.
2. We can't manipulate the DOM directly via C# (e.g. to insert a stylesheet or remove an element or similar), it must be updated via JavaScript, which means putting JavaScript literals in our C# code.
3. The mechanism to run arbitrary JavaScript on the page after load (InvokeScriptAsync()) requires making a function call, which means everyone (including Microsoft in sample code) seems to be calling eval() in many places. If we're going to have to run script to manipulate the page.
4. It swallows mouse and keyboard events. Our app (a kiosk app) resets to the idle state when the user is idle for more than some predetermined number of seconds, but in order to listen for those events we had to listen for mouse move and keydown events in JavaScript and bubble them up to the app (as well as in the surrounding app).
5. There's no clear way to implement a handler for browser modals, both JavaScript-triggered (e.g. confirm(), prompt()), and navigation triggered (e.g. handling resubmission of POST data when refreshing a page that was requested by post).
6. There's no easy way to clear all session data including cookies. Calling ClearTemporaryWebDataAsync() doesn't clear session and other cookies, and HttpCookieManager doesn't have the ability to clear all cookies either. This makes it hard to ensure two kiosk users don't see each other's private session information.
7. When the URL is updated by JavaScript (e.g. in an Angular app) there's no navigation events fired on the control (only ContentLoading()).
8. It's extremely cumbersome to update the user agent string, which makes it hard for the remote site to handle the request loaded in an app in this way specially. There's also no easy way to inject request headers, or other similar methods to affect the behaviour.

[adambarlow]

As mentioned during the community call, I have posted an update to the proposal with a link to the draft spec for the WebView2 API.

Please take a look and let us know your feedback. If you see a missing API check the IWebView2WebView interface as it might be covered in the proposed core WebView2 object.

[michael-hawker]

@adambarlow, is posting in this thread the best place for feedback on the spec?

I think it's great the string returned will be a JSON object, but is there a reason it's re-string-ified vs just coming back as a System.Text.Json object? Calling out a more complete example for the JavaScript side of the WebMessageReceived in that section would be clearer as well (from a documentation perspective).

Also, looks like the WebView1 WebResourceRequested event is missing. This is important for caching and filtering scenarios. The IWebView2WebView interface has a weird comment about it being deprecated and to use the 'new' one, but then there's no new one called out or documented... FYI @pagoe-msft

[michael-hawker]

Also @adambarlow @pagoe-msft, please see feedback on original WebView provided by community as found here: https://www.suchan.cz/2016/04/make-webview-great-again/

Think main points I don't see improvements on around the API surface are around access to navigation stack and cookie management.

[phraemer]

@adambarlow
In our current product we use WebView.AddWebAllowedObject to inject a class into the JS environment for calling back from JS running in the WebView.
It looks like we'd have to use window.chrome.webview.postMessage.postMessage now instead.

However, some of those methods in the web allowed object return an ArrayBuffer. I.e. the class looks something like this:

    [AllowForWeb]
    public sealed class Foo
    {
    	public IAsyncOperation<IBuffer> bar(string arg)
    }

    webView.AddWebAllowedObject("myFoo", new Foo());

	// The object returned is 'thenable'
	let bufferPromise = await new Promise(resolve =>
      myFoo.bar("stuff").then(resolve),
    )

I may be missing something but it's not clear to me how that can be achieved with the new API.

[adambarlow]

@phraemer, we want to enable AddWebAllowedObject, this is mentioned in the 'scope' section of the proposal above as a 'should'. This won't be in the first alpha, but this is something we want to have for release. This would likely be on the corewebview WinRT object, not on the XAML element itself.

[felixse]

Do you have any plans on providing an API to intercept web notifications?

Also wondering if there will be an option to isolate storage/cookies per instance instead of per application scope.

[adambarlow]

@felixse the API for that is planed for the core webview object. The cookie isolation is something we would like to have but are planning to focus on in the next version.

[hanneslarsson]

Is there any dates, or estimated dates regarding the release of a WebView based on EDGE Chromium to be used from within UWP (Xamarin.Forms)?

[michael-hawker]

🦙 @hanneslarsson Adam showed a preview during the last community call starting here and mentioned that hopefully an early preview of it would be released in February.

[hanneslarsson]

@michael-hawker Awesome!! Super thanks for the update! I’m so looking forward to the new webview!

[adambarlow]

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

[ygoe]

Does this also allow editing the HTML content with JavaScript disabled? I'd like to build an e-mail viewer and editor that has JavaScript disabled for security, but also allows editing a reply with the original message quoted inline in the editor. Various input events need to be handled by the application here to update the formatting accordingly. As well as an API to manipulate the DOM with the use of toolbars and other UI commands (set font, insert images, tables and such).

Also, loading of remote resources like images needs to be restricted for privacy, unless it's allowed by an option. Is this supported, too?

[noseratio]

Does this also allow editing the HTML content with JavaScript disabled?

@ygoe have a look at ICoreWebView2Settings::put_IsScriptEnabled. I'm not sure though if you'd still be able to manipulate the DOM with ExecuteScript if you disable scripts.

I myself currently still use the legacy WebOC for its simple text editing features.

[codendone]

@ygoe The HTML content is run out-of-proc from the XAML app, and it is not possible to access the DOM from the app. JavaScript would need to be enabled, at least for the script you want to run.

For your second question, I believe that will be possible via the WebResourceRequested event.

[andrii-pukhkalo]

Working on all OS versions where WinUI 3 is supported is certainly a goal, as called out in the scoping section. We will be able to get more specific moving forward about supported endpoints for the v1, but we really love getting this feedback. The user removing the Edge browser will not be an issue as the APIs necessary for the WebView will be available as part of an OS update.

@adambarlow, is there progress in the availability of WebView2 and WinUI in general for the Xbox platform? Can we expect a Prerelease this year that will include this?

[hansmbakker]

is there progress in the availability of WebView2 and WinUI in general for the Xbox platform? Can we expect a Prerelease this year that will include this?

same question for Windows IoT Core

[johnnylq]

@adambarlow
Is there any target date When can SDK support WinUI3 get officially public released?

[codendone]

@johnnylq From the Windows UI Library Roadmap:

WinUI 3 was shipped as a series of preview releases throughout 2020. We expect to ship Project Reunion 0.5 in late March 2021, which will include the first stable, supported version of WinUI 3.

You can find the most recent release here.

[predavid]

This control has been supported since the Windows App SDK 0.5 release earlier this year. With that, this Issue stands closed.