I've spent the last few weeks integrating a web based sametime chat client into websphere portal and ran into a curious problem. It seemed that on occasion the buddy list would not populate, all I'd get is a dojo busy indicator, but if I refreshed the page everything would be fine.
Time to open up firebug.
I have to admit that dojo isn't the easiest javascript to debug, they've really stretched the capabilities of the language, but I finally tracked it down to a piece of code during the execution of:
ST_Client = new sametime.WebClient({}, "STClient");
At some point it tests if it should display the buddy list right away or add the task to a queue for later execution, and in this case it was adding to the queue. So who is supposed to deal with the queue, and why wasn't it being done? Turns out that there's some code executed in the login
stproxy.login.loginByPassword()
that iterates through the queue and displays the buddy list. I was running into a race condition because I was trying to log in to the samtime server before showing the buddy list, but in some cases the login was finishing before the call to create the WebClient was done.
The Fix?
Ensure that the code creates the WebClient
before it tries to login. Go figure.