This is an important change for those who want modern web rendering on Windows without the large deployment footprint required by the Chromium Embedded Framework (CEF).

Why WebView2 Matters

Until now, Windows HTML rendering in DesktopHTMLViewer has primarily relied on CEF. While CEF provides excellent compatibility and a consistent Chromium-based rendering engine, it also comes with a substantial deployment cost. Including the required CEF runtime files can add well over 200 MB to an application’s distribution size.

Using CEF also means applications are tied to specific Chromium and CEF versions bundled with the app itself. Keeping current requires continuously rebuilding and redistributing newer CEF releases as Chromium evolves and security updates are released.

WebView2 changes that equation considerably.

Because WebView2 uses the Microsoft Edge rendering engine already present on many modern Windows systems, applications can avoid bundling a large embedded Chromium runtime entirely. Security and changes to WebView2 are handled through the operating system via Windows Update, rather than requiring applications to ship and maintain their own browser engine updates.

WebView2 Runtime Requirements

One important consideration is that WebView2 may require the Microsoft Edge WebView2 Runtime to be installed on the target system.

Windows 11

Most Windows 11 systems already include WebView2 as part of the operating system, so no additional installation is usually necessary.

Windows 10

Many Windows 10 systems already have the runtime installed because Microsoft distributes it through Edge and Microsoft 365 updates. However, older or managed systems may still require a separate runtime installation.

Applications that depend on WebView2 should verify runtime availability during installation and, if it is not present, either prompt the user or provide a link to download and install the required runtime.

You can also check DesktopHTMLViewer.IsAvailable at runtime to determine whether WebView2 is available.

Microsoft provides the runtime here:
https://developer.microsoft.com/en-us/microsoft-edge/webview2/

WinUI Targets Use WebView2 by Default

For WinUI desktop targets, WebView2 is now the default (and only) HTML rendering engine for the DesktopHTMLViewer. In addition, any new projects created in Xojo 2026r2 or later will default to using the WebView2 engine whenever a DesktopHTMLViewer is added to the layout.

Enabling WebView2 in older projects or non-WinUI Windows targets

For traditional Windows desktop targets that are not using WinUI, you can still opt into WebView2 support by enabling the HTMLViewer uses WebView2 option in the Advanced Windows build setting in the IDE:

When enabled, DesktopHTMLViewer will use WebView2 instead of CEF for HTML rendering.

This gives you the flexibility to choose between:

• smaller deployment size with WebView2, or
• fully self-contained deployment with CEF

depending on the needs of your application and target audience. However, moving forward we will be transitioning away from CEF entirely, and it is likely that we will no longer support or update our CEF based HTMLViewer in future releases.

Differences from CEF

Although both CEF and WebView2 are Chromium-based technologies, there are some behavioral differences you should be aware of:

• You may notice some subtle differences in how WebView2 returns results for JSON.Stringify when executed using ExecuteJavaScriptSync. i.e. the result coming back may be quoted.
• executeInXojoSync is supported, but it uses JavaScript Promises to simulate synchronous behavior, so existing code may need to be updated to use async/await. Example: const result = await executeInXojoSync("addNumbers", 2, 3);
• A WebView2-specific cache folder is created alongside the executable. If that directory is not writable, the cache folder is instead created in the user’s local AppData directory.

Final Thoughts

The addition of WebView2 support for DesktopHTMLViewer is a major improvement for Windows desktop deployment in Xojo, and reducing runtime size by hundreds of megabytes while still delivering modern Chromium-based rendering is a significant win.

Those who require rendering consistency or offline/self-contained deployments may still prefer CEF, but WebView2 offers an excellent modern alternative that better matches the direction of the Windows platform itself.

For now, you can choose between either engine depending on your needs, but moving forward we believe WebView2 is the preferred path on Windows. Happy browsing!

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Consistent Barcode Scanning Experience

Not to be outdone, the Barcode scanning experience on Windows has been brought up to par with other platforms, now including support for video mirroring in the scanning window. Also, if you were seeing a “squished” video before, we’ve now added support for a wider range of video devices and aspect ratios.

DesktopHTMLViewer Improvements

Thanks to some feedback we received, the DesktopHTMLViewer now supports raising the FocusReceived, FocusLost, KeyDown, and KeyUp events.

While DesktopHTMLViewer.Print works well, there are times you might want to go straight to PDF. If you’d rather skip the default print prompts, you can now use the new DesktopHTMLViewer.PrintToPDF(file As FolderItem) method to print HTML content directly to a PDF file. Just pass in the destination file and everything else works just like the regular Print method, including the PrintComplete event firing on success.

We’re always working to make Xojo better, and your feedback plays a big part in that. So from all of us here at Xojo—thank you! We truly appreciate your input as we continue to improve the product for you and everyone who uses it.

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

If you’re encountering display anomalies with the DesktopHTMLViewer on a Pi 5 running Bookworm OS, rest assured you’re not alone. This issue stems from the version of WebKitGTK the DesktopHTMLViewer relies on. While efforts to address this persist, a viable workaround exists: disabling hardware acceleration when utilizing WebKitGTK. Fortunately, in Xojo, we’ve facilitated this by exposing an environment variable. You can conveniently set this variable before the creation of the DesktopHTMLViewer, such as within your App.Opening event.

To turn hardware acceleration OFF, you can assign that to the WEBKIT_HARDWARE_ACCELERATION environment variable:

System.EnvironmentVariable("WEBKIT_HARDWARE_ACCELERATION") = "OFF"

By default, hardware acceleration is enabled/disabled as requested by web contents, but you can also force hardware acceleration to be enabled even for websites not requesting it:

System.EnvironmentVariable("WEBKIT_HARDWARE_ACCELERATION") = "ON"

To revert it to its default state, simply assign any value other than ON/OFF. While we remain optimistic that this issue will be resolved at some point, in the interim, this environment variable stands ready to function as a temporary solution.

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube