MSHTML for Windows about go-webview2

[jchv]

These are explicitly bindings for WebView2, not general webview bindings. I considered adding a fallback a long time ago, but it's reasonably far out of scope for what this has become.

If you need a library that supports both, you'll probably want to use an old version of the webview/webview library. There's a (probably untagged) point in its history where it supported MSHTML, EdgeHTML and had Go bindings at the same time, making it fairly convenient. It does, however, by nature, require CGo.

If you are interested in working on MSHTML bindings for Go that conform to this WebView interface, I am happy to provide assistance or any knowledge I happen to know about making CGo-less bindings. Unfortunately, I do not believe I can commit to making them myself at this time, and so I must close this issue.

[3052]

it just seems at this point in time that making EdgeHTML only is a mistake, as I suspect a large percentage of Windows users wont have the runtime pre-installed, so you are knowingly forcing them to install it. I usually prefer to make installation of my software as simple as possible, which directly contradicts this situation.

contrast with MSHTML, which is pre installed on every Windows computer since the 90s, and even today. so can you provide some context of why EdgeHTML is worth the installation burden that it puts on the end users, other than "shiny new thing"?

[jchv]

These are bindings for WebView2. If you don't want to depend on WebView2, then you shouldn't use these. It's not a generic webview library, it's WebView2 bindings. Sorry.

And I would not mind writing MSHTML bindings separately from this repository, but I don't even run Windows anymore. I've always been primarily a Linux user and have a lot of trouble keeping up with maintaining Windows-only software. I would like to try to keep maintaining go-webview2 and other related projects, but the fact is, it would be silly for me to commit to adding even more scope to this project.

contrast with MSHTML, which is pre installed on every Windows computer since the 90s, and even today. so can you provide some context of why EdgeHTML is worth the installation burden that it puts on the end users, other than "shiny new thing"?

I wrote this library because I was using webview/webview, which already uses WebView2, however it requires CGo + a separate DLL included with your application, Webview2Loader. go-webview2 doesn't require CGo and it doesn't require Webview2Loader to be bundled next to your application, so you get a single EXE that works anywhere where WebView2 is installed.

By design, "bindings for WebView2" are going to depend on "WebView2". Supporting a fallback is basically out of scope. This package does use a common defacto standard interface, so it'd be possible to implement both WebView2 and MSHTML bindings (in another package) and have them be selected dynamically at runtime (by your app).

However, there is a particular reason why WebView2 is more interesting than MSHTML: It's much faster, supports a vastly greater number of standards, has better support for integrating into applications and supporting things like pen/touch. It has a heavier footprint, but in exchange it is a much more modern browser engine in every regard. If you implement a library that selects WebView2 or MSHTML, you basically have to be prepared to make sure that it works with both at any given time, which limits you significantly both in how deeply integrated you can make the web view, as well as what you can actually get running inside of it.

If you want to write an application on top of MSHTML, you are going to need to either make or use existing MSHTML bindings; these are WebView2 bindings, this repository will never contain bindings for MSHTML even if I did write MSHTML bindings.

[3052]

thanks for the detailed response, sorry if I came off too aggressive. you have some good points. my use case is very simple, I want to capture a cookie from the Google login process. in other situations, I would just set up some situation with OAuth, but in this case the scope is Google Play, which I dont think Google exposes publicly. so for my situation I think a WebView is one of the only solutions. did you have any recommendation, or would you agree that WebView is a good option?

[jchv]

WebView may be a viable way to approach this, but unfortunately you might find that it's a bit difficult. I'm not sure how well-enforced it is, but Google nominally tries to block embedded webviews from doing Google authentication (maybe this only applies to OAuth2/OIDC, but I recall being bitten by this for normal google auth.) Google authentication is generally a pretty big pain in the ass in my experience, and I haven't really tried to mess with it in a while; hopefully it's calmed down a bit since last time I looked.

sorry if I came off too aggressive

Not a huge problem, I was not really terribly bothered or anything like that, and I am definitely not opposed to MSHTML bindings, I just don't personally have the time to work on them right now. I do hope you find a good solution for your needs.