Browser support in SWT has always been a complicated story. By default (meaning without any hint from the application developers and the users), SWT relies on “native” renderers (Internet Explorer on Windows, WebKit on macOS and WebKitGTK+ or Mozilla/XULRunner on Linux). While supporting different rendering of pages in the Web is common, it’s annoying when you develop a desktop application where the Browser component is used to render things that Web technologies can do better than SWT (CSS, SVG, WebGL, etc.). Not only that, but you would expect high performance from the renderer for such usage.

To mitigate these discrepancies, developers can provide some hints to the SWT framework about which renderer (WebKit or Mozilla/XULRunner) it should use. Unfortunately, XULRunner is deprecated and is no longer built/shipped by the Mozilla team. WebKit is staying, but it brings its own couple of issues when one tries to use it on all platforms:

On Windows, it requires users to have Safari installed. As you may know, Apple has silently killed Safari on Windows back in 2012. Moreover, Safari was only available on 32 bits Windows systems. All in all, you don’t really have a choice: you need to rely on the Internet Explorer renderer when using Windows.

On Linux, it can be difficult to setup a proper working combination of WebKitGTK and GTK+. It is especially true for older Eclipse versions on Linux distros which change GTK+ internals (hello Ubuntu!).

On macOS, it just works™, as expected (it would have been a surprise where the system renderer is WebKit itself).

One solution that has been studied further is implementing the SWT Browser widget on top of the JavaFX browser component (WebView). Unfortunately, it has some compatibility issues with GTK+ versions. Furthermore, it is reported to be slow and to have trouble rendering modern HTML pages due to the usage of an old version of WebKitGTK.