When does (mobile) Safari / Chrome view a page loaded with Comet?

Question

I have a website that uses a comet connection with a long poll. The connection should be configured to load / after the page loads.

Despite my efforts to prevent this, many browsers consider the long poll query as part of the page loading mechanism, thereby preserving the page at the loading stage. In Safari, this causes the progress bar (beyond the url field) to not end. In Chrome, the icon appears as a download icon. Even more problematic is the mobile safari on the iphone, which does not allow you to hide the url field at boot time. Android mobile devices have similar problems on some devices.

In general, the behavior is difficult to reproduce and seems to depend on the speed of the browser / platform / connection / etc. Right now, my code is initiating a long poll of 10 ms after the window.onLoad trigger. This seems to work very often, but not always. I suspect that this may have something to do with loading some external (images / javascript) resources, but it can be said that the onLoad event is fired after they are fully loaded.

Does anyone point out how to get these browsers to view my page as loaded? Ideally, you can somehow mark xmlhttprequest as a comet, but this is not a function :).

Answer 1

I had the same problem, and I found that if you allow the page to exit the onload handler before posting its long ajax request for polling, everything will work fine and the page will not return to loading state.

So, for example, what would usually be

$(document).ready(function() { $.ajax(...); });

will become

$(document).ready(function() setTimeout(function() { $.ajax(...); }, 0); });

In the special case of WebKit, I believe that $ (document) .ready is a synonym for window.onload. Therefore, it is important.

This worked for me on iPad1.1 with iOS 5.

Answer 2

We successfully removed the download indicator in Safari 5.1.5 using ajax long polling requests. Chrome, unfortunately, is still constantly showing a download indicator. For chrome, our team chose to simply change the value of the css cursor to the entire body element (for example: a crosshair or a custom cursor) - a terrible "hack" - but at least the user will not see the load mouse cursor while they are in the system.