Provide compositioning on the WPF

[kekyo]

Similar #20, I need to native composition ability on the WPF.

WPF based projects have many problem for lack of compositioning using WebBrowser (Internet explorer based, legacy and unstable), WebView (Old Edge based, cannot native composited and overlay usage for combined both browser based app and WPF rich UI experience).

Another solution, we can use CefSharp. But it cause problem for touch-based gesture controls and bit trouble for native binary deployment.

I heard and welcomed chrome based Edge (and component). If new Edge component will have ability for WPF native composition, I think we can solve and better application many native apps situation.

[Fxztam]

Yes, right - hybrid applications in WPF & Edge Chromium WebView bundles two rich UI experiences. I hope for the next step (and cant wait) : The integration into WPF !!!

[david-risney]

We're currently looking into how best we can integrate WebView2 into .NET including into WPF. We can share more details when we have them in the future.

Can you elaborate on the issues you had with the WebBrowser and WebView in WPF? Is it sort of z-order / airspace issues?

[psmulovics]

Any plans to provide it for .NET Core 3.0+ based WPF?

[liminzhu]

@psmulovics we're working with the .NET team to figure out the right shipping vehicle and supported versions. I'd imagine the control would at least work on the latest .NET Core (or .NET 5.x) version when it becomes available. Are you currently on .NET Core 3.0?

[psmulovics]

Yes, and planning moving to 3.1 as that would be LTS. My hope is that the control would be agnostic like the new winui controls are.

[kekyo]

@david-risney My project uses WebView1 on WPF, it composes both web-based GIS application and complex UI element (on WPF.) The WPF UI elements have three sublayers which have to show road traffic lanes (by a lot of polylines) and source-destination markers. These layers are receiving user interructs by touch-gesture and mouse, synchronizes between WPF layers and WebView1 when user interuct scrolling, zoom up and down.

Currently, WebView1 doesn't have ability of WPF-based compositions. So, cannot implement naturally composition/overlaying with standard WPF technics. My dirty solution is it constructed two WPF window and placed WebView1 into lower window, and place UI elements into higher window. And synchronizes all controls (scrolling, moving, zooming etc...) both windows. It's pretty hard for implementation, upgrading feature and maintaining.

I'll ignore if these problem has only this project. But I think to might have same problems for using WebView1.

[david-risney]

Those sort of issues are definitely a concern for us and we're looking into how we can solve them in the UI frameworks with which we're integrating. Its too early for us yet to say what the behavior will be for WPF but we are working on it.

[meteorsnows]

Doesn't had to provide similar feature as Electron. That can be phase 2 if there is enough traction.

Web is the always winning ground in IT for now, until possibly next generation of youngster takeover. Possibly even new kind of device. Please put enough workforce to it. To be able to handle development of edgeChrome as Chrome.

Maybe try to be similar as https://github.com/GoogleChromeLabs/carlo

[kekyo]

I don't know how easier and cooler way on Electron (I feel maybe pretty good solution.) We have to climb upstairs for own tech knowledge if we get these cool features totally covered. And I feel it means will put into bin all knowledge about .NET, Windows and WebView(1/2).

I wanna how to integrate smoothly and/or easier web systems/services on the .NET, include ASP.NET and web browsing technology. WebView1 was given for us how to it on (only) UWP. But WPF got it with halfway. We are receiving a force have to choose liked ecosystem or another (young) way near future...

[pagoe-msft]

Hi @kekyo and @meteorsnows,

We are working hard on the new WebView2 and integrating it with WPF. What painpoints have/did you experience with WebView1 and WPF? What are some things you'd like to see in WebView2?

Thank you so much for the Feedback!

[psmulovics]

To start - it was not chrome. Finished.

[kekyo]

@pagoe-msft Feel good news! WebView1 features implemented on the Win32 user32/gdi (I know handled HWND based). That means it cannot do natively compositioning on WPF. If we try to do composition both WebView1 and WPF, we have to split Windows (System.Windows.Window) and an application view puts on one window and WebView1 puts on another one.

  ---------------   (Display surface)
     ---------      Application view puts on overlay window based System.Windows.Window, contains transparent backgrounds
     ---------      WebView1 view puts on System.Windows.Window

This solution too complex, the dirty topics are:

• Application cannot receive input events easier. (mouse hover, click, keyboard and touch interactions on both window. We have to handle and combine receiving events from both windows without WPF's default event tunneling/bubbling routers. And I experienced it's very strange the events came and lost, not understandable...)
• We have to handle window sizing/moving features with synchronizes both windows. (If window moving on the desktop, we have to move synchronizes both windows. Resizing are same.)
• Completely separated application UI elements and WebView1. It's harder (not flexible) to complex placing elements (example stacking: UIElement -- WebView1 -- UIElement, that means have to place 3 windows! exactly we have to synch and manage these windows)

I imagined these limitations come from WebView1 implementation based on Win32/Window (HWND) system, same as ActiveX component problems on WPF. I wanna WebView2 makes on native WPF UIElement (or FrameworkElement) component, not HWND based.

[kekyo]

INFO: CefSharp's implementation is good way because it's native control on WPF, it can handle truly compositioning, smooth way using with WPF knowledge (but it has minor troubles/bugs.)

[david-risney]

Thanks for the great description of the issues with the WV1 WPF control. We will look into integrating well with WPF and try to avoid these problems. Thanks!

[antti-j]

Chromium based Edge is expected to be generally available on January 15 2020. Can we expect any WebView2 WPF support before that?

Will WebView(1) continue working after stable Edge is installed?

[david-risney]

Thanks for your questions!

• We're currently working on .NET support and it should be available in the first half of next year with a dev preview sometime earlier than that.
• Installing stable Edge doesn't affect existing edgehtml/mshtml WebViews/WebControls. Existing WebViews/WebControls will continue to work for the foreseeable future regardless of whether the new Edge is installed.

[fosJoddie]

Just want to leave my comments about what I hope WebView2 will provide. The basis of my comments are either to make sure they are not forgotten when moving from Webview1 or problems with how things are currently implemented:

• A way to place WPF controls above the Webview. In other words, allow the Webview to be partially or fully blocked by other gui elements like dialogs. (I realize this is a major airspace conundrum)
• A way to inject/set cookies from code and likewise to clear them on demand.
• Blocking of context menu
• Allow calling of javascript methods from code
• Allow DOM manipulation either through a javascript interface or directly

[david-risney]

Thanks @fosJoddie,

• WPF WebView control airspace issues: We're aware of this issue and it will be a tough one. We'll likely have at least a dev preview of .NET support out before we can fix the airspace issue.
• Cookies: This looks like feature request #4
• Blocking context menu: We have just added a setting to disable default context menus.
• Calling JavaScript methods: We have a ExecuteScript method for injecting script.
• DOM manipulation: Will ExecuteScript work for this as well? Injecting script that can modify the DOM?

[agonzalezjr]

Hello, can't wait for this support on WPF!

@david-risney, just wanted to add: together with ExecuteScript to go from C# to JS, there should also be support for notify to send data from JS to C#. Please see https://docs.microsoft.com/en-us/uwp/api/windows.web.ui.interop.webviewcontrol.scriptnotify

[david-risney]

Thanks @agonzalezjr! Yes we currently have a WebMessageReceived event and PostWebMessageAsJson/AsString to send and receive messages to and from the web content.

[kekyo]

@david-risney I posted #75 wanna support interop for window.notify().

[agonzalezjr]

@david-risney AsJson 🙌 Thank you!

[tgraupmann]

We're currently looking into how best we can integrate WebView2 into .NET including into WPF. We can share more details when we have them in the future.

Can you elaborate on the issues you had with the WebBrowser and WebView in WPF? Is it sort of z-order / airspace issues?

I made an attempt to render the WebView2 control in a WPF Sample app. Unfortunately, it's not rendering, but here's a start with this fork. https://github.com/tgraupmann/WebView2Samples/tree/master/WpfWebView2APISample

I was following this guide on how to show Win32 controls in WPF. https://docs.microsoft.com/en-us/dotnet/framework/wpf/advanced/walkthrough-hosting-a-win32-control-in-wpf

A WPF and UWP sample for WebView2 would be great.

[kekyo]

@tgraupmann It's interesting sample for me! Does it have native WPF compositioning? As far as I know win32 (HWND based) hosted method can't composition natively.

[david-risney]

@tgraupmann, yes thanks! When we have WPF/WinForms support and UWP support we will definitely have sample code for those.

[michael-russin]

@tgraupmann I've been doing some work on getting the WebView2 working in .net also. Check out webview2-control There is a demo for WPF and one Windows Forms.

[alvichan]

@david-risney We have been using CefSharp WPF. We found that CefSharp WPF doesn't support accessibility (https://github.com/cefsharp/CefSharp/issues/2053). Screen readers like JAWS and NVDA cannot recognize HTML element rendered by CefSharp WPF.

I hope WebView2 will support accessibility.

[antti-j]

Is the WPF support discussed here same or different than the WinUI 3.0? WinUI 3.0 Alpha seems to now have WebView2 support for UWP in preview https://docs.microsoft.com/en-us/uwp/toolkits/winui3/ And WinUI 3.0 is said to support WPF too.

[liminzhu]

The WPF support discussed here is about natively hosting the control in WPF. I believe the WinUI WebView2 support in WPF is about hosting the WebView (or any other XAML control) through XAML island.

At the end of the day, both are/will be built on top of the win32 C++ Chromium-Edge WebView2, but are different hosting model.

[darbid]

Just landed here from searching for WPF and webview2. Please please stop being lazy and build a proper WPF control that then does not suffer from airspace problems. Cefsharp does it so Microsoft should be able to manage it too.

[pagoe-msft]

Hi everyone,

We have released our .NET WebVIew2 preview! Check it out here: https://docs.microsoft.com/en-us/microsoft-edge/webview2/releasenotes#09515-prerelease

[sondreb]

"Announcement: WebView2 now supports Windows Forms and WPF on .NET Framework 4.6.2 or later and .NET Core 3.0 or later in the pre-release package"

By the wording of this, will WebView2 only support Windows Forms and WPF on either .NET Framework or .NET Core? It doesn't sound like there will be support for cross-platform .NET Core executables?

[liminzhu]

Windows Forms and WPF on either .NET Framework or .NET Core

Yes

It doesn't sound like there will be support for cross-platform .NET Core executables?

WebView2 doesn't support any non-Windows environment as of now, but we're definitely open to hearing what platforms you need webview2 on :).

[sondreb]

Was hoping WebView2 would be supporting the platforms where Microsoft Edge is available, at least Mac and Linux (which is coming).

The use case is that I have a lot of applications that is developed in .NET Core, that hosts UI built on web-technology. The most used technology for this is Electron, but that brings with it the full Chromium and Node.JS runtime. Both brings with them larger size and bigger resource footprint than is needed.

The main logic runs on .NET Core, don't need Node.JS. And being able to rely on native webview will save resources and don't need embedded the full browser engine. The fallback today is launching the users default browser, which is not a very good solution, especially considering that plugins etc. can be an issue.

Other alternatives for this is "WebWindow", the proof-of-concept that Steve Sanderson made and "webview-cs".

It is very unfortunate that there are no way to build a modern app on .NET Core with web-based UI, that's how most apps are built these days. Just looking at my desktop right: Spotify (web player), Outlook (PWA installed through Edge), pinterest (PWA installed through Edge), Visual Studio Code (Electron), GitHub Desktop (Electron), Steam (mostly web based rendering), Discord (Electron), Microsoft Teams (Electron), Slack (Electron).

Without a way to build these apps using .NET Core, then developers will eventually migrate to other platforms such as Node.JS (and now Deno which does TypeScript).

[dangershony]

WebView2 doesn't support any non-Windows environment as of now, but we're definitely open to hearing what platforms you need webview2 on :).

We're building a Bitcoin node on dotnet core 3.1 so that it's cross platform and using web-ui technology for the wallet UI, but this would be greatly improved if the UI could run in it's own window env rather then browser or the massive Electron framework.

[darbid]

If I were you dangershony I would have another look at cefsharp (the only true WPF browser) and all the other Chromium projects. Building a webview2 dependent app for cross platform which would in turn be dependent on the user using a Microsoft built branded browser ie. Edge Chromium is arguably a waste of time. Looking at browser usage for Edge eg. Have a look here I would not be building anything which was dependent on a MS Browser. And the 5% of people that do use a MS browser do not do it by choice they are forced to by some IT admin or it was installed by default on Windows 10 (so not cross platform).

Electron uses Chromium, Webview2 (Edge Chromium) also uses the same Chromium projects which means no difference in the size of the framework which will be supporting your app.

[sondreb]

CefSharp is interesting, but it requires WPF or WinForm hosts, correct? So it's just like WebView2, except that one needs to include the whole Chromium runtime.

Building a webview2 dependent app for cross platform which would in turn be dependent on the user using a Microsoft built branded browser

WebView2 has been announced to be able to install itself on computers that don't have the webview installed. Being able to use such a functionality would be great.

CefSharp and Electron requires including Chromium in the distribution, if one can rely on native webview available in the OS, it would be less to distribute and I would expect less resource usage, but perhaps not.

It also appears that CefSharp require .NET Framwork to be installed?

.NET Core support
As of version 75.1.142, the CefSharp NuGet packages can be used with .NET Core 3.0 projects (as shown by the examples). However, the current versions have some limitations that you should be aware of:

The target machine still needs to have .NET Framework 4.5.2 or higher installed, as the CefSharp.BrowserSubprocess.exe is still used.

I'm using Microsoft Edge as my primary browser as it connects to Microsoft accounts, as oppose to Google accounts. Use both of them all day long.

The reason why I'm requesting this feature, is that the industry (of app development) seriously need to migrate away from having to include/embed the app runtime with every single application. The web technology capabilities are fairly mature so it's no longer about compatibility, just being able to rely on the native webview installed on any OS (desktop or mobile) is a great benefit.

[kekyo]

I'm not sure if the new WebView2 implements it using the raw user32 API to handle drawing and input.

I'm concerned if the WebView2 core library directly uses a set of APIs starting from HWND.

Because WPF compositioning cannot be achieved by any related method, and porting to other environments too (UWP, etc.) Will eventually have to be compromised by relying on HWND.

For example, if WebView2's core library separates by a pure framebuffer and an abstracted input API (it is without the user32 API), Win32, DirectX, Windows Forms, WPF, UWP, or other multi-platform target architecture is really fits.

(That is, it is best to abstract the interface of WebView2's core library in a form that doesn't depend on HWND and prepare a wrapper library for each target platform.)

As far as I can see from the sample code that came out early in this issue, the interface design was implemented on an HWND basis, so WPF should have failed to get composition. If the implementation goes the same way, I think it's difficult to fix this later...

[darbid]

Have a look here at all the opportunities of embedding a chromium webbrowser if you can just do it in C++ then you are set.