DesktopHTMLViewer using WebKit renderer - how?

The documentation states: “Used to specify the rendering engine used on Windows. Choices are Native (0) or WebKit (1). You can only set this property in the Inspector for the control.” (

I feel stupid, but how?? There is no such property in the Inspector for the DesktopHTMLViewer (2021r3.1).

So, how do I enable WebKit properly?

It does appear to be completely missing from the inspector in 2021r3.1. Switch to the classic HTMLViewer and file a ticket.

I had a feeling that under r3, we are all using webkit on all platforms was there not something about this in the release notes?

1 Like

Ah, I had not been aware of that. Thanks for the info / thread.

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)

AFAIK, the advice here:

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.


100MB that is.

1 Like

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]

1 Like

I honestly don’t know if this is a Bug, or a Documentation problem (e.g. this big change was made, but never mentioned in release notes).



I would expect you get newer WebView2 with the new Windows control listed in the roadmap.
But for now you can use WebView2ControlMBS from us.

1 Like

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.

1 Like

As far as I could see on the web page, it is not possible to purchase the plugin individually, but only the whole MBS “Complete” plugin bundle?

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…

For Example: Using Webkit :

Using HTMLViewer using Native Renderer.


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.

Thanks for the update…


You can email us. We have a link somewhere, I think: Order here

But in general, you can buy the Complete set to get 40 plugins.

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. :slight_smile:

Edited (I hope) for clarity.