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

Michael Jumper commented on GUACAMOLE-327:
------------------------------------------

{quote}
Finally, IE 10 and IE 11 are not able to download filetypes the browser will 
automatically try to open (like .txt and .jpg files). The download appears to 
just not do anything. The same remote system is able to download other 
extensions like .exe and .zip download just fine. This is true for either 
method (the menu file browser or the guacctl utility).
{quote}

I am not able to reproduce this. This was definitely an issue prior to 
0.9.12-incubating, but should have been fixed through GUACAMOLE-129. Retesting 
the functionality within IE11, that much seems to work as expected.

> File upload/download issues in IE
> ---------------------------------
>
>                 Key: GUACAMOLE-327
>                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-327
>             Project: Guacamole
>          Issue Type: Bug
>          Components: guacamole-client
>    Affects Versions: 0.9.12-incubating
>            Reporter: Shaun Tarves
>            Assignee: Michael Jumper
>
> Internet Explorer, including 11, doesn't have support for location.origin so 
> when trying to build the URL for the XMLHttpRequests in 
> tunnelService.downloadStream and tunnelService.uploadToStream, the string 
> "undefined" gets prepended onto the URL, rendering that functionality 
> unusable.
> The workaround/polyfill for this is pretty simple and well documented on the 
> web and is basically:
> {code:javascript}
> if (!window.location.origin) {
>   window.location.origin = window.location.protocol + '//' + 
> window.location.hostname + (window.location.port ? (':' + 
> window.location.port) : '');
> }
> {code}
> reference: https://gist.github.com/hbogs/7908703
> Additionally, IE seems to have a problem with the fallback code for removing 
> the download iframe from the body. If the iframe is successfully removed by 
> the callback of the iframe.onload handler, the stream.onend callback 
> encounters an error because the iframe is no longer attached. A check for 
> iframe's parentElement being defined is a workaround:
> {code:javascript}
> stream.onend = function downloadComplete() {
>             $window.setTimeout(function cleanupIframe() {
>                 if (iframe.parentElement) {
>                     document.body.removeChild(iframe);
>                 }
>             }, DOWNLOAD_CLEANUP_WAIT);
>         };
> {code}
> Finally, IE 10 and IE 11 are not able to download filetypes the browser will 
> automatically try to open (like .txt and .jpg files). The download appears to 
> just not do anything. The same remote system is able to download other 
> extensions like .exe and .zip download just fine. This is true for either 
> method (the menu file browser or the guacctl utility).



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

Reply via email to