wxWebView Edge Chromium Backend

[Tobias T]

Hi,

I've created a PR for a Edge Chromium Backend.

https://github.com/wxWidgets/wxWidgets/pull/1700

For those not following microsofts strange browser plans:

At the end of january Microsoft will release a new edge browser based on chromium which will be pushed to Windows 10 computers

and will be available from Windows 7 and up.

This browser can be integrated via the WebView2 SDK into applications and will obviously a better alternative than Internet Explorer.

But I'll need some feedback/ideas on integration:

At link time a 2-3 static methods from a WebLoader2.dll are used which has to be provided with your application. This would obviously make the webview library dependent on the DLL. I think a good idea could be to load these methods from WebLoader2.dll dynamically. This would allow wxWidgets binaries to be built with wxUSE_WEBVIEW_EDGEC defaulting to ON and it would just work if WebLoader2.dll is provided with the application.
Further more it would probably be interesting if this backend is used if available automatically if available (currently the sample checks if it's available before using it).

Any ideas are welcome (please comment in the PR)

Thanks,

Tobias

[Vadim Zeitlin]

On Thu, 9 Jan 2020 05:42:03 -0800 (PST) Tobias T wrote:

TT> I've created a PR for a Edge Chromium Backend.
TT> https://github.com/wxWidgets/wxWidgets/pull/1700

Hi,

Thanks and glad to see you back with more awesome contributions (and I
don't use the word "awesome" lightly or commonly)!

TT> For those not following microsofts strange browser plans:
TT> At the end of january Microsoft will release a new edge browser based on
TT> chromium which will be pushed to Windows 10 computers
TT> and will be available from Windows 7 and up.

I had no idea it would be made available even for Windows 7. This seems to
indicate that they're really serious about making it ubiquitous.

TT> This browser can be integrated via the WebView2 SDK into applications and
TT> will obviously a better alternative than Internet Explorer.
TT>
TT> But I'll need some feedback/ideas on integration:
TT> At link time a 2-3 static methods from a WebLoader2.dll are used which has
TT> to be provided with your application. This would obviously make the webview
TT> library dependent on the DLL. I think a good idea could be to load these
TT> methods from WebLoader2.dll dynamically.

Yes, if it's just 2-3 methods, I think it's the best choice.

TT> Any ideas are welcome (please comment in the PR)

I'll try to look at it slightly later.

BTW, I also really, really wanted to get back to your HTTP(S) client PR
during Christmas vacation but unfortunately couldn't do it. I'd still like
to merge it before 3.2.0...

Thanks again!
VZ

[Tobias T]

TT> But I'll need some feedback/ideas on integration:
TT> At link time a 2-3 static methods from a WebLoader2.dll are used which has
TT> to be provided with your application. This would obviously make the webview
TT> library dependent on the DLL. I think a good idea could be to load these
TT> methods from WebLoader2.dll dynamically.

 Yes, if it's just 2-3 methods, I think it's the best choice.

I've now included the single header file from Microsoft Edge WebView2 into 3rdparty/webview2 and load the 2 required methods

dynamically from WebView2Loader.dll

With this I've enabled wxUSE_WEBVIEW_EDGEC per default for all supported compiler versions (VS2015+). An application

can use wxWebView::IsBackendAvailable() at runtime to check if wxWebViewEdgeChromium is usable.

The WebView2Loader.dll has to be extracted from the nuget package. It might make sense to include it in binary distributions

of wxWidgets.

I think it makes sense to have a mechanism to automatically use wxWebViewEdgeChromium, but I'm not sure yet how.

Simply using it when available from webview might break existing apps expecting Internet Explorer on the other end there

are probably many applications that just want to display something in the most modern browser engine available on the

users system.

[Eric Jensen]

Hello Tobias,

Friday, January 10, 2020, 1:40:30 PM, you wrote:



TT>> But I'll need some feedback/ideas on integration:
TT>> At link time a 2-3 static methods from a WebLoader2.dll are used which has
TT>> to be provided with your application. This would obviously make the webview
TT>> library dependent on the DLL. I think a good idea could be to load these
TT>> methods from WebLoader2.dll dynamically.

TT>
TT>  Yes, if it's just 2-3 methods, I think it's the best choice.

First of all, thanks for working on this!

TT> TT> I've now included the single header file from Microsoft Edge
TT> WebView2 into 3rdparty/webview2 and load the 2 required methods
TT> dynamically from WebView2Loader.dll
What exactly does this DLL do?

Does it have any other effects, i.e. can CRTs still linked both
statically and dynamically?

Eric

[Tobias T]

TT>  TT> I've now included the single header file from Microsoft Edge
TT> WebView2 into 3rdparty/webview2 and load the 2 required methods
TT> dynamically from WebView2Loader.dll
What exactly does this DLL do?

The DLL is basically the entry point that loads the msedge.exe and handles communication with it.

It's 4 entry points are shown here: https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2/reference/webview2.idl

 

Does it have any other effects, i.e. can CRTs still linked both
statically and dynamically?

As the DLL is loaded dynamically I can't imagine any side effects.

[Vadim Zeitlin]

On Fri, 10 Jan 2020 04:40:30 -0800 (PST) Tobias T wrote:

TT> I've now included the single header file from Microsoft Edge WebView2 into
TT> 3rdparty/webview2

Unfortunately, this seems problematic because the licence states:

Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.

i.e., AFAICS, this forces all applications statically linking with
wxWidgets to abide by this requirement and include this copyright notice
into their distribution (when linking dynamically it could be argued that
it's enough to include it in wx itself, although I have trouble seeing how
can we realistically do it).

TT> and load the 2 required methods dynamically from WebView2Loader.dll

Declaring these 2 functions ourselves wouldn't be a problem neither, but
defining the interfaces they use probably will... I'm really not sure what
to do here, but I don't think we can just wash our hands of the need for
the library users to respect the licence above because clearly nobody will
do it. If there is no better solution, I'd rather disable support for this
by default and ask people to download and make available (during compile-
and run-time, respectively) both the header and the DLL themselves, as then
we can be reasonably sure that they would be at least aware of the need to
provide the copyright notice.

TT> With this I've enabled wxUSE_WEBVIEW_EDGEC

Sorry for bikeshedding, but am I the only one who finds "edgec" cryptic?
Personally I'd be fine with just "edge", I think, but if we want to
emphasize that it's Chromium-based, I'd rather call it "edge_chromium"
which would be IMHO much clearer, even if longer.

TT> per default for all supported compiler versions (VS2015+).

Out of curiosity, what kind of special compiler support does the new code
require to prevent it from being used with the older MSVS versions and gcc?

TT> An application can use wxWebView::IsBackendAvailable() at runtime to
TT> check if wxWebViewEdgeChromium is usable.
TT>
TT> The WebView2Loader.dll has to be extracted from the nuget package. It
TT> might make sense to include it in binary distributions of wxWidgets.

Again, I'd rather prefer people to do it themselves because of the
licence. I also guess this DLL will become available in a future version of
Windows itself, won't it?

TT> I think it makes sense to have a mechanism to automatically use
TT> wxWebViewEdgeChromium, but I'm not sure yet how.
TT> Simply using it when available from webview might break existing apps
TT> expecting Internet Explorer on the other end there
TT> are probably many applications that just want to display something in
TT> the most modern browser engine available on the users system.

Are there any regressions compared to the IE backend? I.e. is there
anything that works with it but not the new one? If not, I think it's
reasonable to use the new one by default -- provided it's enabled at
compile-time.

Regards,
VZ

[Tobias T]

i.e., AFAICS, this forces all applications statically linking with
wxWidgets to abide by this requirement and include this copyright notice
into their distribution (when linking dynamically it could be argued that
it's enough to include it in wx itself, although I have trouble seeing how
can we realistically do it).

Unfortunately you are probably right, it's to bad as it complicates usage.

But with proper build instructions it should probably not be to bad.

 

I'll change the defaults and document what has to be done in wxWebView documentation.

TT> With this I've enabled wxUSE_WEBVIEW_EDGEC

 Sorry for bikeshedding, but am I the only one who finds "edgec" cryptic?
Personally I'd be fine with just "edge", I think, but if we want to
emphasize that it's Chromium-based, I'd rather call it "edge_chromium"
which would be IMHO much clearer, even if longer.

I'm fine with wxUSE_WEBVIEW_EDGE and will unify the naming that C was just to

differentiate from the previous Edge integration, but as that is not happening and

the new Edge will simply be called that it's probably fine to keep that short.

 

TT> per default for all supported compiler versions (VS2015+).

 Out of curiosity, what kind of special compiler support does the new code
require to prevent it from being used with the older MSVS versions and gcc?

It's not so much compiler features as it's at least Windows SDK 8 which includes

wrl/event.h which enables relative easy event handling to. This could be refactored

not to use these templates, but that's work I wont be doing.

 

 Again, I'd rather prefer people to do it themselves because of the
licence. I also guess this DLL will become available in a future version of
Windows itself, won't it?

It's my understanding that this loader DLL (x86/amd64) will remain part of the SDK.

 

TT> I think it makes sense to have a mechanism to automatically use
TT> wxWebViewEdgeChromium, but I'm not sure yet how.
TT> Simply using it when available from webview might break existing apps
TT> expecting Internet Explorer on the other end there
TT> are probably many applications that just want to display something in
TT> the most modern browser engine available on the users system.

 Are there any regressions compared to the IE backend? I.e. is there
anything that works with it but not the new one? If not, I think it's
reasonable to use the new one by default -- provided it's enabled at
compile-time.

The currently unsupported features are the following: virtual filesystems, custom urls,
text selection, find, source code. 

Some of these could probably be implemented.

But I think if the Edge backend isn't enabled by default it's probably not as important

to automatically use it, as the developer is already doing something active to enable it.

[Tobias T]

I've finalized the changes so far and added the build instructions to the wxWebView documentation page:

https://github.com/TcT2k/wxWidgets/blob/webview_edgec/interface/wx/webview.h#L282

It's obviously not as convenient to use, as it would be if enabled by default. But it should be easy enough.

[Avner Aharoni]

I am struggling to build the webview2 dll based on the instructions here: https://wxpython.org/Phoenix/docs/html/wx.html2.WebView.html , the SDK here https://www.nuget.org/packages/Microsoft.Web.WebView2 does not contain either the setup.h or a cmake file. It is also not clear how to build it. Any help would be deeply appreciated.   

[Tobias T]

The SDK is just the webview components SDK. The setup.h and or CMake files are found in the wxWidgets repo.

Please note that the instructions are meant for wxWidgets itself. Building the Python wrapper with customized settings is probably documented somewhere else.