Updates to Lightstreamer JavaScript, iOS, and OS X Client Libs

A new release of the stable version of Lightstreamer is now available, containing updates to:

• JavaScript client library
• iOS client library
• OS X client library

JavaScript Client Library

The new version is 6.1.1. It fixes an issue with Chrome browser version 33 and newer, where a harmless request for a page named "null" was performed to the web server. If you are interested in the technical details, you can find them at the end of this post.

Several other fixes and improvements have been added to the lib. For example, browser's cookies are no more needed in most cases. For a full list of changes, please see the detailed changelog.

How to Update the JavaScript Library

If you are using version 6.0.x of the library, you can replace the lib file with the updated file.
You can download it from the online custom generator or download the full Lightstreamer 5.1.1 distribution and extract the needed file.

In any case, for the paid editions of Lightstreamer, you need to get updated production licenses to authorize version 6.1 of the lib. If you have a valid maintenance contract in place, please contact support@lightstreamer.com to get your updated license files.

iOS and OS X Client Libraries

A few bugs have been fixed and improvements added.
The new version of the iOS lib is 1.2.4, while the new version of the OS X lib is 1.0.3.

See the detailed changelog for full details (iOS changelog; OS X changelog).

To update your clients, download the full Lightstreamer 5.1.1 distribution and extract the needed files. Make sure you go through the changelog to know if any compatibility issue exists when upgrading from your current version if the libs.

Tech Details on the Chrome Issue

To make a long story short, an empty iframe inside the page might be created in some cases, as part of the WebSocket fallback mechanisms of the Lightstreamer JavaScript client library. Usually, we populate it using the "about:blank" page; but, unfortunately, there was an issue with Chrome browser. Pointing such frame to "about:blank" generated an entry in the history and we didn't like that. On the other hand, not pointing it anywhere (i.e.: creating the iframe without ever assigning anything to its src property) did not fit our needs.

Luckily enough, setting its src to null fixed both issues. So, we tried to use null everywhere but that was not working as we wanted on other browsers. Having no way to use feature detection to verify if we had to use null or "about:blank" (well, at least without generating unwanted history entries), we had to resort to UA sniffing.

UA sniffing is usually a bad practice but unfortunately there are cases when you don't have other options. In any case, if you have to resort to it, it is important that the code you write works somehow even if it fails to correctly detect the browser.

And then, Chrome 33 happened... Using null as src for the generated iframe makes the new browser send a request to the web server as if we had set the src to "null". The library still works (mission accomplished) but if you look at the developer console, you'll see that a 404 error is received every time the application is loaded.

We have now fixed the library. In version 6.0, the iframe was created in any case even if not needed. Since version 6.1, the creation of such iframe is lazy, so you'll only see it if you use the enableSharing method (and only if actually needed, based on the way you use such method). Furthermore, "about:blank" does not generate an entry in the history anymore.