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.
What was I thinking? The nature of a race condition is two or more asynchronous threads that affect each other in an undesirable way. Switching the order of the two statements doesn't really fix anything, it just seemed that way because the timing changes in certain cases.
ReplyDeleteThe real fix is to ensure that login is complete before trying to create the WebClient(). I just use this instead:
stproxy.login.loginByToken(null, null, null,loggedInOK, loginFailed);
// This executes *after* login success
function loggedInOK() {
ST_Client = new sametime.WebClient({}, "STClient");
}
function loginFailed() {
alert('Doh');
}