Posted on May 12, 2016

Chromium 49

JxBrowser 6.4 is based on Chromium 49.0.2623.110. This is fairly cool, because apart from general compatibility with the latest web standards, this Chromium engine solves tricky tasks, which were hard to accomplish in some previous versions, like displaying WebGL content on Linux platforms, and enabling incoming audio RTP streams. Also, in Chromium 49, PDF Viewer UI has been updated. So, now you can enjoy the new look, when displaying PDF documents in JxBrowser.

Plugins support

There were some big changes, too. In this Chromium build support of NPAPI plugins has been removed at all. Now, NPAPI plugins such as Microsoft Silverlight, Java Applets, etc. are not supported. The “–enable-npapi” Chromium switcher does not work either. PPAPI plugins such as Adobe Flash work well with this Chromium build. So, if you have to use NPAPI plugins, we recommend that you stick to JxBrowser versions up to 6.4.

Further plans on OS support

Chromium team announced that Chromium 50 drops support of Windows XP, as well as Windows Vista, and Mac OS X 10.6, 10.7, and 10.8, since these platforms are no longer supported by Microsoft and Apple. So here we are giving you a heads up related to these platforms, and we will, too, let them rest in peace, when we are ready with the oncoming update based on Chromium 50 or higher.

Features & Improvements

  • WebGL on Linux support has been added. In previous JxBrowser versions, WebGL did not work on Linux platforms, because Chromium did not start GPU process for rendering WebGL content. Once we upgraded to Chromium 49, WebGL started working as expected on Linux platforms.
  • In JxBrowser versions based on Chromium 43, there was an issue related to incoming audio RTP streams support. Alas, it just does not work with Chromium 43. With Chromium versions before 43 and Chromium 49 this issue is not reproducible. So, now incoming audio RTP streams are officially supported in JxBrowser.

Below let us list the issues that, however, no longer endanger your development process.

  • The placeholder text used to stay visible while a user was already typing in a text area. Happy to say it does not in the new release.
  • A surprising black rectangle used to show up instead of a scroll bar when a PDF Viewer window was resized. This issue was reproducible only on Windows 8.1 and higher. Upgrade to Chromium 49 fixes this issue.
  • You will not see the IllegalArgumentException error when you right-click PDF Document.
  • No more native crashes in Chromium renderer process, at least not when your app finds a DOM HTML element by ID string with a single quote. The issue was in WebKit DOM functionality that did not handle such situation. We applied several patches to WebKit source code that fix the issue.
  • You have no installed printer devices? This is not a reason for failing of the printing functionality on Linux. Now, if there’s no available printer devices, we do not ask Chromium engine to print web page at all. To print web page using printer, at least one printer device must be installed.
  • Deadlock in JavaScript-Java Bridge used to happen under several circumstances. For example, when loading XML document and executing JavaScript code in the ScriptContextListener.onScriptContextCreated(ScriptContextEvent event) method. If we execute JavaScript code in XML document, it will be executed in a separate JavaScript world. As result, the ScriptContextListener.onScriptContextCreated(ScriptContextEvent event) method is invoked again and the code will be blocked in the synchronized Browser.executeJavaScriptAndReturnValue() method. To solve this issue we enabled reentrancy support in JxBrowser IPC functionality and modified synchronization logic in the Browser.executeJavaScriptAndReturnValue() method.
  • BrowserView now retains its focus context, even after showing/hiding the context menu, so users can type texts in the text field normally after closing the context menu. The issue has been fixed by updating focus context info when showing/hiding context menu.
  • In multi-threaded environment we used to see see the “Deadlock in safepoint code” error that came from JxBrowser JNI code. To fix this issue we made sure we create and access JNIEnv variable in the same thread.

Download JxBrowser 6.4

Go Top