Question

I have an html/javascript frontend that is using JQuery’s AJAX request to send XML containing user-entered form data to a backend application which in turn creates a PDF from that information. The frontend receives a UUID in response, which it then uses in the download url to download the generated PDF.

This works wonderfully in Firefox and Safari, but is being blocked by Internet Explorer 8’s protection against scripted downloads. Telling IE8 to download the file via the spawned Information Bar forces a reload of the page, which blanks out all of the entered user content.

A single onMouseUp event on a button-esque element is triggering the generation of the XML to send, sending the XML, getting its response, then initiating the download via setting the url in the window.location object. Separating out that download into a different button (having one generate and send the xml and fetch the UUID, and the other only initiate the download using the url made from the UUID) bypasses the information bar but ruins the simplicity and intuitiveness of the interface.

Here are the relevant javascript functions:

function sendXml()
{
    var documentXml = generateDocumentXml();
    var percentEncodedDocumentXml = escape(DocumentXml);
    var url = "generate?document=" + percentEncodedDocumentXml;
    $.ajax({
        url: url,
        type: "GET",
        dataType: "xml",
        success: function (xml)
        {
            var uuid = $(xml).find('uuid').text();
            getPdf(uuid);
        },
        error: function (xhr)
        {
            alert("There was an error creating your PDF template");
        }
    });
}

function getPdf(uuid)
{
    var url = "generate?get-pdf=" + uuid;
    window.location = url;
}

I’m fishing for suggestions about how to best handle this issue. My first preference would be to have the information bar not interfere at all, but minimizing its harm would be a dramatic improvement over the current situation. If it could not reload and wipe the frontend interface, and actually proceed to downloading the file when the user chooses to “Download File…” via the Information Bar’s menu, that would help.

Answer 1

I tested it and the reason for the bar to occur seems to be the fact, that there is no direct relation between the user-action(mouseover) and the loading of the URL(guess a PDF-file).

This workaround will solve the issue:

Create an iframe(may be hidden) inside the document and use

window.open(url,'nameAttributeOfTheIframe') 

…to load the PDF. The bar occurs too, but if the user chooses to download, the current document will reload too, but the user-content(if you mean form-data) will remain, as the bar belongs to the iframe not to the parent document.

Be sure to send a attachment-header with the PDF too, to beware of showing it inside the browser(if the browser is able to), because if you use a hidden iframe the user cannot see what’s loaded there.

<iframe name="nameAttributeOfTheIframe" style="display:none"></iframe>
<input type="button" value="click here"  onclick="f1()"/>
<input value="default value">
<script type="text/javascript">
<!--
function f1()
{
   //simulate delayed download
   setTimeout(f2,1000)     
}

function f2()
{
  window.open('http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf','nameAttributeOfTheIframe');      
}

document.getElementsByTagName('input')[1].value='this is modified value, should remain';

//-->
</script>