I just added a DesktopHTMLViewer to a new project in 2021r3 and noticed that the renderer property is missing so I can’t select Native as the renderer. I checked the docs, it mentions the Renderer property and talks about Native at length, but the entry is goes to a missing link, I checked the patch notes and can’t see any mention of this, was this removed or left out in error?
You can subclass DesktopHTMLViewer and bring that option back.
Edit: don’t know if that will make a difference using Windows, don’t know how to test
For Windows, the HTMLViewer is now WebKit. There was already functionality that couldn’t really be ported reliably to the native renderer due to that functionality being missing from whatever version of the built-in renderer might be installed on whatever version of Windows a user might have. This was a change to improve consistency.
1 Like
Ouch. So instead of giving us a modern WebView2 version, they force us to use CEF? Well that complicates life.
3 Likes
To me, it doesn’t really matter if they use WebView2 or CEF for the Windows HTMLViewer renderer. It’d be nice to have slimmer package sizes for distribution, but I’d much rather have a dependable cross-platform HTMLViewer, and I trust that they’ve either weighed the options and chosen CEF as the best way to implement this or will reevaluate the engine used going forward.
I’m not sure what versions of Windows actually support WebView2, so I can’t comment on that, but I’m sure it was a concern.
https://docs.microsoft.com/en-us/microsoft-edge/webview2/
https://docs.microsoft.com/en-us/deployedge/microsoft-edge-supported-operating-systems
Important
** We will continue to support Microsoft Edge on Windows 7 and on Windows Server 2008 R2 until January 15, 2023. These operating systems are out of support and Microsoft recommends you move to a supported operating system such as Windows 10.
1 Like
I do prefer CEF embedded than sending the user to the MS website to download the WebView Runtime if his app crashes. Webview2 - Microsoft Edge Developer
My issue with CEF is it leaving zombie processes behind and blocking the installer. It’s easier for me to avoid CEF entirely. WebView2 when available, native with edge mode when available, or nothing otherwise. More work for me, but more reliable for end users.
My problem will be if I put DesktopHTMLViewer on the window for the Mac version, that’s now going to include CEF, even though I won’t be using it. I guess I need to use an MBS control for Mac (and Linux if that happens) instead of the built in control now.
I’m really loving the new controls. /s
That’s exactly what I’m doing. I have both a legacy HTMLViewer and a WebView2ControlMBS on the window. I test first for the Windows version. Below 10 I’ll just use the legacy control. On 10+ I test for WebView2, then make visible/load the appropriate control. I’m seeing no problems.
I think the Mac/Linux versions use native WebKit as always. Happy to know if I’m wrong. 
That’s correct. You can’t use CEF on either even if you want to. With built-in stuff, that is.
Where I quoted you, were you saying that CEF bloated the Mac build size anyway? I haven’t tried that, and it would be a huge change.
No, it’ll bloat the Windows size even though it’s not used at all.
1 Like
Precisely why I’ve stuck with the old control, choosing between it and WebView2, even on windows I’ve already converted to DesktopWindow. 
I think I reported this issue in the past and Xojo said it was fixed few releases ago.
I had all sorts of problems with alien Windows installations and broken/hacked native engines (people disabled IE/Edge and native engine or something), so the way I solved it was ALWAYS embedding CEF. And that is my preference from that time forward, at least for some years to come. No complaints since.
I just saw one the other day, but I was remote debugging and ended the session by closing the tab in the IDE rather than closing the debugged app properly, so it can still happen with crashes.
But I do expect that an orphan CEF process detects/timeouts and close, I don’t know how long it takes to. @William_Yu could clarify?
1 Like
I waited a few minutes before I had to kill it with Task Manager.
If confirmed, the bug wasn’t really fixed or we have a regression.
1 Like
I think it’s probably an instance where it just wasn’t reported/reproduced at the time. I don’t know for certain that it still happens with crashes, it’s just speculation because of what I saw where the app didn’t spin down properly and close those processes because I was remote debugging and just killed the session.