[jira] [Comment Edited] (GUACAMOLE-128) Clipboard sharing can crash IE

["Michael Jumper (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GUACAMOLE-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15847888#comment-15847888 ] 

Michael Jumper edited comment on GUACAMOLE-128 at 9/4/17 11:31 PM:
-------------------------------------------------------------------

There are two things at work here that I can find thus far:

# IE11 is remarkably slow when it comes to pasting data into a {{<div>}} with {{contenteditable="true"}}. Adding logging before and after the various parts of clipboard handling, it is the call to {{document.execCommand('paste')}} which delays things, racks up CPU, etc. For the test data provided, it takes 2 - 5 seconds for the operation to complete.
# Something is causing the paste attempt to occur multiple times, even though the clipboard has not changed. This probably has something to do with a difference in the way IE11 handles focus/blur events, as this doesn't occur in the other browsers.

The above combined cause IE to become effectively unusable while the clipboard contains sufficient data. Fixing the multiple pastes should be possible, though I'm not sure what to do about {{contenteditable}}; having such a {{<div>}} is necessary if we are ever to support copy/paste of images and rich text. -Reverting back to a {{<textarea>}} is not an option.-

EDIT: Reverting back to a {{<textarea>}} is exactly what we've done due to GUACAMOLE-310.


was (Author: mike.jumper):
There are two things at work here that I can find thus far:

# IE11 is remarkably slow when it comes to pasting data into a {{<div>}} with {{contenteditable="true"}}. Adding logging before and after the various parts of clipboard handling, it is the call to {{document.execCommand('paste')}} which delays things, racks up CPU, etc. For the test data provided, it takes 2 - 5 seconds for the operation to complete.
# Something is causing the paste attempt to occur multiple times, even though the clipboard has not changed. This probably has something to do with a difference in the way IE11 handles focus/blur events, as this doesn't occur in the other browsers.

The above combined cause IE to become effectively unusable while the clipboard contains sufficient data. Fixing the multiple pastes should be possible, though I'm not sure what to do about {{contenteditable}}; having such a {{<div>}} is necessary if we are ever to support copy/paste of images and rich text. Reverting back to a {{<textarea>}} is not an option.

> Clipboard sharing can crash IE
> ------------------------------
>
>                 Key: GUACAMOLE-128
>                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-128
>             Project: Guacamole
>          Issue Type: Bug
>          Components: guacd-docker
>    Affects Versions: 0.9.10-incubating
>         Environment: Ubuntu 16 using docker containers from latest 0.9.10
>            Reporter: Robin
>            Assignee: Michael Jumper
>             Fix For: 0.9.14-incubating
>
>
> Using internet explorer 11 with "programmatic clipboard access enabled" you can crash the browser and consume high CPU on the client when placing a large amount of data on the clipboard.  (1600 lines of text is enough)
> A work around is to disable "Programmatic clipboard access"  - While this works on other browsers and is almost certainly an IE 11 issue it would be a good feature to detect the client browser and disable this functionality to prevent a crash.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)