I came across a real puzzle, and I was hoping that someone out there could shed light on my problem.
The application I am writing is a JS-based client for what is essentially a desktop sharing service. The service captures images from the desktop, encodes them as base64 encoded jpegs, and sends them via websocket to the JS client. Then the client displays these images (as URIs of data), users can move the mouse around the image and also click on the image, these mouse events are encoded as XML commands that are queued and served by a timer every 15 ms, so the queue can be cleared of redundant or repeated commands before sending to the service. These commands are then executed (generate click events on the desktop, move the mouse, etc.), and new desktop images are generated and the cycle continues.
The whole system works very well, with the exception of some very inconsistent behavior in Safari on the iPad. Essentially, when a user moves a finger across the screen, the client seems to block (or possibly de-prioritize) incoming messages on the website, in favor of only sending outgoing messages. The way this manifests itself is that as you move your finger, the display will not refresh as long as you touch the screen, and then when you lift your finger, the stream of image updates will be received using onMessage ( ), which are then quickly animated on the screen.
Mobile Safari is the only browser that appears to behave this way, none of the desktop browsers or any of the Android tablets I tested show the same behavior.
I started logging in to the inbound and outbound methods on the website, and this confirms the behavior I saw. In Safari, I get a lot of outgoing messages in a line, followed by numerous incoming messages, while on Android I will see incoming and outgoing messages alternating when you drag your finger across the screen, as a result, the display on Android will continue to update as how do you drag your finger.
The main reason why I suspect that the website is the culprit is because the client has a backup mechanism, so if the browser does not support web support, a couple of XHR objects are created (one for incoming and one for outgoing) and used instead of websocket. If I force mobile Safari to use XHR instead of websites, the problem will disappear. In this case, only the communication mechanism changes (all the code for recording input events and displaying images remains unchanged).
I understand that this is a rather specific problem, and without code it will be very difficult to diagnose, but I decided not to send the code simply because of the huge amount of code in the client.
If someone sees behavior similar to what I described, or I know any potential reasons for this behavior, I would really appreciate your input.