This is not the question you asked, but do you really need to enable WebKit (CEF)? Many people have trouble with the HTMLViewer on Windows, not realizing that it defaults to IE6 level rendering.
If you set the right registry keys, you get the latest IE11 engine - which is not perfect, but is pretty good.
(I built a large JavaScript/Xojo app and found the IE11 engine to be “good enough” and much simpler than including the extra baggage)
in the section entitled “Windows IE Version” is still valid. That section resulted from research I did a couple of years ago after my app’s HTMLViewer did not work properly on Windows: the javascript crashed every time on initialisation. Finding out what was behind that and how to fix took quite some poking around.
As a fan of “just works”, without peeking the system and trying to fix it to my needs playing with the registry, MAYBE breaking something else that the user depends on with the settings that are there, and after some headaches with systems of my users with their “native” engines broken, I decided always to add that ridiculous small 100MB CEF engine that allows me to use executeInXojo() and executeInXojoSync() that I need and no regrets so far.
So, FOR ME, using “native” is a burden, not a solution.
To be honest, I am not sure if I really need to enable WebKit, but Google pointed me to some answers where this was mentioned. I just tried to play around with it to figure out, if it helps with my actual problem.
My actual problem: I want to retrieve the dimensions of my web page I am displaying in the HTMLViewer in order to adjust the control dimensions accordingly. Google thinks, that I need JavaScript for that and therefore WebKit as well.
But as others already said, it seems that WebKit is the default now, and JavaScript is in fact working (but somehow still does not return the correct dimensions - but that is a different issue, I suppose).
Confirmed: HTMLViewer works as epected, but DesktopHTMLViewer seems to only support WebKit/CEF.
The overhead for the WebKit renderer is about 200MB, actually. A simple “hello world” app is 40MB with the native renderer, but over 240MB with Webkit. [Testing in a 64 bit app. 32 bits may be “only” 100MB]
For now, I am superimposing the MBS control on top of a legacy HTMLViewer (using Native.) Which one to load, and render visible, is decided after testing for WebView2 availability (also done within the plugin.) This nicely saves the WebKit overhead in the built app, which in itself was roughly twice the size of the rest of the code combined.
Hi there, I not so sure about this statement, when I upgraded to API2 and obviously webkit as the renderer for my HTML viewer my compiled app actually shrunk from 26mg down to 18meg, I was using the native renderer before. No one has really be able to explain the massive decrease in compiled application size after the change, so I’m not sure that webkit is the culprit…
I am referring to build size on Windows. If you use WebKit, Xojo will bundle more than 100MB worth of Chromium stuff into your app. WebKit is built-in on Mac (and on Linux, though it may be optional on some distros.)
I could have been more specific, but I thought it implicit because the “WebKit/Native” issue is always in the context of Windows. The WebView2 (with MBS) option I mentioned is also strictly a Windows thing.
These look like Mac screenshots. In this respect you didn’t change anything when you switched from “Native” to “WebKit”. The old HTMLViewer always used WebKit on Mac and Linux, with the “Native” setting being irrelevant. On these platforms, WebKit “is” native.
The build-size difference, that you mentioned, is interesting. I’m only guessing but it might be that the new DesktopHTMLViewer has less overhead, with no Windows “Native rendering” support that might still compile as cruft into other targets. Be assured, though, that on Windows your app will be a monster. Heck, I’d have to look to see if I could get a Windows “Hello World” into your size.