Details
-
Bug
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
1.5.2, 1.5.3
-
None
Description
When using a tunnel that relies on XHR rather than websockets, parseResponse in Tunnel.js calls parse.receive(current, true) when xmlhttprequest.readyState is 3 or 4. When the readyState is 3, setInterval is used to periodically call parseResponse to check the state, until reaching readyState 4. This means that the parser.receive call can be made multiple times for one request. This is supposed to be fine, since we're setting isBuffer to true, which means we should send in the same message, with anything new simply tacked onto the end. The startIndex and elementEnd variables in receive should simply keep track of where we last left off, and only parse any new instructions. However, this is not what's happening. Instead, they are getting reset each time and the entire message is parsed again, re-executing the same instructions. This was really clear in our customized version of guacamole, as we've added our own instruction which adds an icon to the top right corner when something is enabled. Due to this issue, the icon was duplicated many times. I've made a hotfix in our copy of the js which fixes this when isBuffer is true and retains the existing behaviour when it's false. I can provide this in a pull request, though I'm not sure if you'll want to use this change or rework the whole function.
Note: I believe this bug came in with d6a01c28e56edb0b0d3bab4459b1f1a75414e999 so it would affect 1.5.2, too, though I've only tested with 1.5.3.