Cheat Sheet of the Browser Tab DOM Events

This diagram tries to connect the various DOM events with the visual and executing state of a web page.

The events are displayed as „quoted text“, while the event targets are (parenthesised).

When the page is In-Memory-Cached the execution of JavaScript is suspendend. This is known as „Back-Forward-Cache“.

In his blog post Don’t lose user and app state, use Page Visibility Ilya Grigorik, a Google engineer, recommends using the Page Visibility API events („hidden“ and „visible“ arrows in my diagram) to decide putting the app into the background and out again. As you can see in reality this is not quite so simple, since the visibilityChange events fire not always reliably.

Was sind Themes im yalst Live Chat und wozu brauche ich sie?

Ein Theme für das yalst-LiveSupportTool ist eine Textdatei im XML-Format, in der das Aussehen der Fenster auf der Besucherseitebeliebig angepasst und verändert werden kann.
Dieses erfolgt dabei für jeden Zugang/Lizenz separat, so dass bei einer Mehrlizenzinstallation bzw. auch bei der von Visisoft gehosteten Lösung eine Änderung des Designs, der graphischen Elemente, der Funktionalitäten, der Textausgaben möglich wird.
Dabei überschreiben die Einstellungen in den Themes alle anderen Einstellungen. Das betrifft sowohl die Installationseinstellungen, die der webbasierten Konfiguration als auch die im yalst-LiveSupportTool fest integrierten Eigenschaften.

AJAX on web page unloading

On page unload AJAX network requests are sent by all browsers if – contrary to the general advice – the synchronous flavour of XMLHttpRequest (SJAX) is used.

Encoding of null and undefined in a type-safe URI query

When transferring variables in the query part of an URI, encode the JavaScript value null in key=null as ?key. Distinguish between undefined, null and an empty string by omitting the key altogether for undefined and appending an equal sign for the latter. I.e. ?key= stands for key=““. Use the URI.js as helper library for URI query extraction and composition.

Configure RequireJS to load the yalst live chat JavaScript Api


For loading outdated versions of the Visitor Chat JavaScript Api ensure the release version of RequireJS does finish loading it’s data-main script before fetching the Visitor Api.

Update – this post’s solution is now obsolete (1. Aug. 2014)

The co-existence problems of the two RequireJS libraries have been resolved with the version 2.1 of the VisitorAPI. The VisitorAPI library is distributed from now on as a single JavaScript file too. That source file is AMD loader compatible. Thus the VisitorAPI v. 2.1 no longer introduces global variables in the JavaScript context.

The whole loading code condenses down to:

The details are discussed in this tutorial.

The Original Problem

The RequireJS library adds support for Javascript modules which is missing in the current webbrowser implementations.
The yalst Visitor Api uses a renamed RequireJS (version 2.1.9 at the time of writing) for code organisation and loading, and so may the client pages themselves.
However since RequireJS does not provide a noConflict() method both versions can interfere on the page resulting in Javascript errors.

RequireJS in the Visitor Api

The Visitor Chat JavaScript Api provides the namespace LiveSupport which

  • under the namespace LiveSupport.VisitorAPI contains the documented public methods and
  • under the root contains it’s own version of RequireJS.

Thus in addition to the documented use these methods are available in the Api too:

The api is put in this namespace by the RequireJS optimiser r.js using a build.js file like this:

The Solution

The client page can use it’s own (non-namespaced) version of RequireJS, given it completes loading the data-main script before the Visitor Api’s namespaced version.

An Example

The example page index-sync.html uses RequireJS in require.min.js with the data-main script main.js to load jQuery, underscore and Lo-Dash.
In this example the <script> tag for the Visitor Api is created „by hand“ [1] in a function called from the data-main script main.js. This tag loads the Visitor Api’s own namespaced RequireJS in LiveSupport.js with the data-main script LiveSupportMain.js which in turn loads the actual api source files.
Among the api files is yet an own version of underscore which by using _.noConflict() is guaranteed to be free of side effects for the client page.

The directory structure and the network activity log of a web page containing both the vanilla version of RequireJS and the namespaced version of the Visitor Api is shown here:
RequireJS NoConflict Loading NetworkLog
Here is the code to accomplish sequential loading of the libraries:

[1] To define the order in which the libraries are fetched by the browser loadScript.js could be used for dynamic injection of <script> tags into the DOM and handling of the load and readystatechange events.

Polling AJAX Using When.js with jQuery AJAX Promises

Abstract: Using when.jspoll command together with jQuery’s Ajax methods yalst operator clients written in Javascript can define their data update loop with a minimal amount of code.


  1. The Problem
  2. The Principle Of Promises
  3. When.js‘ Poll Method
  4. The Monitor Code
  5. References

The Problem

When implementing a web page like the yalst operator console which monitors frequently changing data the most reliable and most compatible method is still rapidly polling of Ajax requests. A number of websocket implementations use Ajax polling as a fallback in case the web socket connection can not be established[1].
Both the issuing of Ajax requests and periodically executing a worker function are common tasks when building web applications and are abstracted in many library implementations.

The Principle Of Promises

A Promise-based interface provides a nice way to decouple the asynchronous internals of the network operation from the application program flow.

A general description is that a promise encapsulates the final result of an asynchronous operation. A promise may be in one of the three states, "pending", "resolved", and "rejected". The promise itself accepts callbacks via its then method.[2]

Which means that instead of specifying callback functions in the call of an asynchronous operation that operation simply returns a promise (so to speak a „promise“ of its eventual result).

This diagram depicts the basic features:
Time sequence of asynchronous I/O using a promise object to wrap the results.

Time sequence of asynchronous I/O using a promise object to wrap the results. The gray box groups an alternative line of execution. [3].

The advantage is that it is easy to compose new promises from existing ones. Examples are

  • The combined promise all which resolves not until all given promises resolve (e.g. loading a bunch of images before displaying the slide show).
  • The competitive promise any which evaluates to the return value of the promise whichever one completes first (e.g. timing out an operation by combining it with a timeout promise)
  • The propagation/forwarding of promises by returning a new promise from a then callback. E.g. when polling Ajax in case the reason for an Ajax failure was a timeout condition the onRejected() handler could resolve a newly created promise with a default value an return that promise. Thus the poll control loop is not interrupted.

Another advantage is that sequential chains of asynchronous logic actually appear sequential with promises rather than with the unwieldy nesting patterns of callback functions [5].

The Libraries

Usually the first candidate for a library implementation is always the well-established jQuery library. Fortunately it’s Ajax objects already implement a promise interface, well done! However to repeatedly poll a worker promise neither jQuery nor underscore i.e.Low-Dash provide suitable methods.

Browsing for other promise libraries the simple API of When.js [4] stands out. It’s features include

    • important combinators like map, all, any, pipeline, sequence, parallel,…
    • convenient utility promises like timeout, delay and poll
    • coexisting with jQuery promises and
    • transforming other callback-based APIs into promise-based APIs, e.g. when loading an image:

When.js‘ Poll Method

The When.js poll method will

„execute a worker task repeatedly at the specified interval ΔT, until the shouldFinish condition function returns true. The resultPromise will be resolved with the most recent value returned from worker. If worker fails (throws an exception or returns a rejected promise) before shouldFinish condition returns true, the resultPromise will be rejected.“ [4]

which is an excellent choice for wrapping the jQuery Ajax worker function for our purpose.

However since there are two different promises involved now the program flow can get confusing. In order to clarify their dependence the next digram depicts all possible outcomes of this combination. Due to this article’s format the time axis is rotated pointing from top to bottom.
Using when.js poll method with a worker function returning a jQuery promise

Using when.js poll method with a worker function returning a jQuery promise. The gray boxes group alternative lines of execution. Please feel free to verify his behaviour in this JsFiddle.

The Monitor Code

As „promised“ here is the final code which defines the monitoring loop in the yalst operator console.


[1] see the section „Pushing and Polling“ at
[3] idea for the diagram shamelessly taken from NetTuts+
[5] David Herman: „Effective Javascript“ , 2012 by Addison-Wesley,

New JavaScript Visitor Api for Chat Events and Actions

The JavaScript Visitor Api for Chat provides a flexible way of integrating pre-chat actions and events; as well as visitor tracking on web pages. E.g. examining the support availability, tracking chat progress and painting click-to-chat buttons are highly customisable.