views:

118

answers:

2

I'm implementing Comet using the script tag long polling technique, based on this page. Following on from my previous question, I've got it all working, except for one annoyance, which only happens in Firefox.

On the initial page load my Comet client JavaScript sends two requests to the Comet server (in the form of dynamically generated <script> tags that are appended to the DOM):

  1. get_messages - this is ongoing poll for messages from the application.
  2. initialise - this is a once-off request at startup.

These two happen at the same time - that is, the <script> tags for both of them exist in the DOM at the same. (I can see them in the Firebug DOM inspector.) The server immediately sends some script as a response to the initialise request, but it doesn't send anything for the get_messages request until there's actually a message, which may take a while.

In Firefox 3.5 the script returned in the <script> tag for the initialise request does not get executed until the other <script> tag (for get_messages) also loads! In Chrome 3 and IE 8 this works fine - the script is executed as soon as it's received.

Why does Firefox do this and how do I fix it? I suppose I could try to work around it on the server by sending a dummy "message" at the same time as the initialise response, but that's quite a hack. I'd like to understand and fix this properly, if possible.

A: 

I'm not sure why this is occurring, but perhaps a simple workaround would be to only add the get_messages <script> tag once the initialise request has completed. (I presume you have some callback that processes the response from the initialise request.)

inklesspen
+2  A: 

Seems to me to be a question of load order. Firefox always ensures that requests queued up execute in the order in which they were requested. IE does NOT ensure this (not sure about Chrome).

Regardless, if you shouldn't be calling get_messages until after the initialize code, you would want to trigger that request in the callback from your initialize function anyway. You'd want to do this no matter what, because other browsers may be inconsistent as well. IE6 for sure doesn't work the same way as other browsers regarding load order - it won't continue loading the DOM until the long-poll request completes, so you'd be stuck waiting around for your long poll interval just to see the main DOM load.

You can check out the source for our javascript client if you want details, we ran into similar issues when building our ASP.NET comet server, WebSync. The source can be viewed here:

http://sync.frozenmountain.com/client.ashx?debug=true

Do a search for "ie6" to see some of the workarounds.

jvenema
Thanks, that makes sense. Unfortunately, it doesn't solve the problem for me, because a get_messages request would be running at any given time and a new subscription request can be sent at any time.I've had to do the hack I mentioned in the original post (and some more), which got it working. I haven't tested in IE6, but thankfully this is for internal users and IE6 is unsupported.
Evgeny