Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
adambarlow opened this issue Nov 21, 2019 · 26 comments
Open

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

adambarlow opened this issue Nov 21, 2019 · 26 comments

Comments

@adambarlow
Copy link
Contributor

@adambarlow adambarlow commented Nov 21, 2019

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

This comment has been minimized.

Copy link
Contributor

@kmgallahan kmgallahan commented Nov 22, 2019

@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

This comment has been minimized.

Copy link

@moshegutman moshegutman commented Nov 22, 2019

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

@jesbis jesbis pinned this issue Nov 22, 2019
@martinsuchan

This comment has been minimized.

Copy link

@martinsuchan martinsuchan commented Nov 22, 2019

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

This comment has been minimized.

Copy link

@michael-hawker michael-hawker commented Nov 22, 2019

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

This comment has been minimized.

Copy link

@hansmbakker hansmbakker commented Nov 22, 2019

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

@shaggygi

This comment has been minimized.

Copy link

@shaggygi shaggygi commented Nov 22, 2019

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

@adambarlow

This comment has been minimized.

Copy link
Contributor Author

@adambarlow adambarlow commented Nov 22, 2019

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

@vitorgrs

This comment has been minimized.

Copy link

@vitorgrs vitorgrs commented Nov 23, 2019

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

This comment has been minimized.

Copy link

@martinsuchan martinsuchan commented Nov 23, 2019

@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

This comment has been minimized.

Copy link
Contributor Author

@adambarlow adambarlow commented Nov 23, 2019

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.

@noseratio

This comment has been minimized.

Copy link

@noseratio noseratio commented Nov 24, 2019

These days, nearly every single Desktop app has an HTML view in some form, and unfortunately, many of them are still stuck with IE WebBrowser-based wrappers. Providing a modern WebView for modernizing those existing apps is a great initiative and is a step in the right direction, thanks for that.

However, if I was to start a new Desktop app development today, I'd be looking for a cross platform UI framework. My team is about to ship a brand new Desktop app for which we've chosen Electron. We also considered Flutter for Desktop, but we haven't looked back to WPF or WinForms.

Thus, apologies if my request is off-topic here, but it'd be great to see some efforts from Microsoft to create a cross-platform HTML rendering shell for .NET Core, based on the new Edge, which is also a cross-platform browser. Then we could use Blazor.NET to create cross-platform Desktop apps. I believe there's a great demand for such toolkit, and it might be the future of the Desktop development.

@fitojb

This comment has been minimized.

Copy link

@fitojb fitojb commented Dec 4, 2019

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

This comment has been minimized.

Copy link

@noseratio noseratio commented Dec 4, 2019

@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

This comment has been minimized.

Copy link

@jschroedl jschroedl commented Dec 6, 2019

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

This comment has been minimized.

Copy link

@kitgrose kitgrose commented Dec 18, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@adambarlow adambarlow commented Jan 22, 2020

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

This comment has been minimized.

Copy link

@michael-hawker michael-hawker commented Jan 23, 2020

@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

This comment has been minimized.

Copy link

@michael-hawker michael-hawker commented Jan 23, 2020

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

This comment has been minimized.

Copy link

@phraemer phraemer commented Jan 24, 2020

@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

This comment has been minimized.

Copy link
Contributor Author

@adambarlow adambarlow commented Jan 24, 2020

@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

This comment has been minimized.

Copy link

@felixse felixse commented Jan 26, 2020

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

This comment has been minimized.

Copy link
Contributor Author

@adambarlow adambarlow commented Jan 29, 2020

@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

This comment has been minimized.

Copy link

@hanneslarsson hanneslarsson commented Feb 7, 2020

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

This comment has been minimized.

Copy link

@michael-hawker michael-hawker commented Feb 7, 2020

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

This comment has been minimized.

Copy link

@hanneslarsson hanneslarsson commented Feb 7, 2020

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

@adambarlow

This comment has been minimized.

Copy link
Contributor Author

@adambarlow adambarlow commented Feb 11, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Feature tracking
Front Burner
API review status
Spec in progress
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.