[
https://issues.apache.org/jira/browse/GUACAMOLE-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shaun Tarves updated GUACAMOLE-327:
-----------------------------------
Description:
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).
was:
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}
> File upload/download 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
>
> 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)
