[
https://issues.apache.org/jira/browse/GUACAMOLE-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper closed GUACAMOLE-1849.
----------------------------------
Fix Version/s: 1.5.4
Resolution: Fixed
> Parser reparses same instructions multiple times in some cases
> --------------------------------------------------------------
>
> Key: GUACAMOLE-1849
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1849
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-common-js
> Affects Versions: 1.5.3, 1.5.2
> Reporter: Darren Foley
> Priority: Minor
> Fix For: 1.5.4
>
>
> 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.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
