Boscop
Windows WebView2 support and the future of this crate
Windows has MSHTML, EdgeHTML and new addition WebView2 (Chromium based Edge):
- https://github.com/MicrosoftEdge/WebView2Samples/tree/master/WebView2APISample
- https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2/gettingstarted
I think MSHTML and EdgeHTML are both not sufficient these days, but WebView2 could make this kind of apps feasible.
EDIT @zxey: see comment for plans
It's mentioned as on the roadmap for the webview project, so assuming this project will stay up to date it will get chromium edge webview support.
https://github.com/zserge/webview/issues/305
Okay, I will close this. Apologies for spammin I was browsing these various "web-view" "webview" projects, and I thought this is the canonical project to report about this.
I had just happened to read that roadmap issue before I saw yours, that's the only way I knew. So pretty understandable that you didn't know about it! :)
Apparently it's already in the Zserge's webview-x branch, see this:
https://github.com/zserge/webview/issues/85#issuecomment-576135118
I wonder can we just now use Webview2 with Rust? Does webview-x branch work with Boscop/web-view?
I think we should reopen this issue until the master branch in the upstream library supports WebView2?
@green-s do you happen to know does it work with this @Boscop's web-view already? I think it's backwards incompatible change. I think this should be closed once this repository is made to support the new webview master branch.
@Ciantic It's not compatible. Most of the API has changed in some way. CSS injection, maximize and dialog have been removed. Another minor issue is that WebView2 currently requires you to distribute a DLL (MicrosoftEdge/WebViewFeedback/issues/110).
Okay, I keep this open.
Requires DLL... sigh the damn Microsoft, I want static binaries 😀
I will try to get to this next weekend. We need to carefully evaluate the fixes and new features we have accumulated over time and see if they still apply to new zserge/webview or if they are fixed and if the features can be implemented.
I wanted to try WebView2 too, so I built a rust wrapper for the WebView2 SDK: webview2. It's not complete but already supports most of the APIs you should need: creation, window message handling, navigating to a URL or an HTML document, and two-way communications, etc. I think it works pretty well.
It uses com-rs and does not require a C/C++ compiler (as a bonus, it works with the gnu toolchain too). The most painful part was implementing callbacks as COM objects. But after some struggling I managed to come up with a callback macro that converts a rust closure to a COM object, like the C++ WRT Callback template class.
The DLL is embedded and does not need to be shipped separately. It is included with include_bytes and extracted to a file and loaded with LoadLibrary at runtime.
@sopium Looks very cool, I got inspired by your work and started rewriting all of webview to Rust so we can continually improve it, I started with gtk which seemed like the easiest one, because it has quite nice c api, you can see it's already merged to master.
Next I continued with mshtml. Why still bother with mshtml you ask? Well, Edge's WebView2 is still in preview and I want to provide reasonable fallback if the user does not have it installed, also it is a really good exercise for COM interop also needed for Edge.
I wanted to translate the original implementation line by line to Rust, but the code proved to be too convoluted to do so. I then found this which is so much more understandable.
So, I started the mshtml implementation taking references from both, the original and this implementation and you can find the results here, it is almost completed, I plan to finish it this week and then merge it with web-view.
If you'd be willing and want of course, I would like to merge your webview2 implementation into web-view and give you rights to this repo so we can improve this together.
The last one will be Objective-C, which honestly I did not look that much into, but will hopefully not be that hard when using the objc crate, seems like it could easily be 1:1 mapping, but I could be wrong.
If you'd be willing and want of course, I would like to merge your webview2 implementation into web-view and give you rights to this repo so we can improve this together.
Hi, thanks for the offer.
I'm not sure that I want to merge my webview2 bindings into this repo. I think it makes more sense to have the webview2 bindings as a separate crate and web-view uses it as a dependency. Or maybe if the org for web-view (#114) is established, develop it under that organization.
The webview2 bindings provides a rich and complete API for the webview (I have generated bindings for all the COM interfaces), and leaves window creation and message handling to the application or other crates like winit (cc #118). By not owning the window, it does not need to worry about all the window related functionalities, e.g. high DPI, show and hide, icons, tray icon and menu, drag and drop, frameless mode, fullscreen etc.
Sure, I will definitely try to integrate it some way. I really really tried hard to use winit, but unfortunately, you cannot use it for all platforms, it is easy to embed webview on Windows and macOS but not on Linux. On Linux with winit you get either X11 handle or wayland connection and we need to have gtk window instead, because we use libwebkitgtk.
@sopium Oh thank god someone else is maintaining this! I got something similar (unpublished, probably way worse) implemented over a few weeks of learning just how much I didn't understand about Rust.... then COVID and timelines all change and we have to use IE instead 😰 And then they have changed the API twice, and there's some runtime thing I don't understand... Thank god for other peoples' work!
I will say, I didn't have much luck with winit but I think that was mostly because I was hitting some edgecase bug, and I wanted to have async wrappers around the callbacks.
I am confused about this crate. The API is not up to date with the C webview. Is this a rewrite or a binding?
I'm also confused. It seems like this is almost becoming a fork or a port at this point? I'd love to get involved and start making some contributions. Has anyone set up a chat channel for this specific project? (I'm aware of the gitter channel for upstream webview)
It is supposed to be a rewrite, but is currently more of a binding because cocoa and winapi werent completely available directly to rust at the time of writing. Winapi is now available to rust and the library needs to be re-written for the same, I was talking about this in #216 . As far as I am aware, there are no chat channels as of now.
Have there been any developments regarding integrating WebView2 into this crate?
@Blakeinstein I looked and didn't see any ability to make a plain webview that supports WebView2. Is this going to be possible with this crate?
@gdavies3 generally the development is going on here: https://github.com/webview/webview_rust it does support WebView2 through the C bindings. (Even the Tauri uses that)
@Blakeinstein thanks for that, I was wondering how that fit in. I will have to take a close look to see if I can work out an example using WebView2 and Rust.
I looked at https://github.com/webview/webview_rust and, though it seems to be actively maintained, there are quirks like lack of title bar text on macOS that don't appear in that crate. If https://github.com/webview/webview_rust is where all the dev happens then what is the point of this crate? Obviously this crate provides additional value otherwise it wouldn't exist and we would be stuck with no title bar on macOS, for example.
This crate is my "go to" for an app that I am developing (probably a similar situation to many others) and the only major thing I need is WebView2 on Windows. My app looks and performs well in macOS and Linux but, for whatever reason, the EdgeHTML interpreter/renderer (and MSHTML, which is even worse) chokes on a standard process.
I am not a developer by training but know how to code. I was really excited when I found Rust, then WebView, because they provide a minimalistic code base from which to work without having to install a million other unnecessary dependencies.
Of course, if needed, I will figure this out myself but I doubt it would be in a form that is decoupled enough to share with this repo. Why doesn't anyone want to tackle this or give detailed information on how someone else could do it? Is this crate, for all sakes and purposes, on the verge of being abandoned? Or is there another approach that we don't see with aims of implementing stable wrappers on top of https://github.com/webview/webview_rust ?
What is the current base way to use WebView2 (Chromium based Edge) on Windows?
