The fail callback is never called when downloading from an ASP.NET Web API call

[christhecoder]

Thanks for providing the community with an excellent library John. I have found one problem though. When making a request to a Web API method that throws an exception, the fail callback is never called, as the library never sees the download as having finished. This is because the body of the iframe is null in this particular scenario. The iframe document does have an Error XML tag containing the error message however, which can also be looked for to indicate completion.

I've written the code to do this, and it works in Firefox and Chrome. However, IE11 throws an access denied error when trying to access the contents of the iframe (but only after the response has been received) - a problem that seems to already exist in this library, so it never gets to my code. Seems to be a known issue with IE, and requires some kludgey workarounds.

Happy to contribute my change though if you'd like.

[johnculviner]

Sure send it over and let me know any other feedback you have. Thanks!

[christhecoder]

Sorry for the late reply John. I've been on a deadline to get this project working on live. There is a weird issue that I want to track down first, where the browser seems to go off into space after the first call to the Web API, with further requests maintaining a status of pending, and never complete. Only seems to happen when calling the Web API - it doesn't happen in your examples. The problem seems to be related to the previous iframes not being removed. I've changed my code to remove them after a short timeout (5 seconds) after the download is complete, but I'm not sure if you want that as part of your code base, as you mention in the comments that problems occasionally occur if you remove the iframes. I need to investigate more, so rather than introduce a possible bug into your library I'll try and solve the issue, and I'll get back to you then.

[johnculviner]

Sure, good luck!

On Feb 26, 2015, at 8:05 AM, christhecoder [email protected] wrote:

Sorry for the late reply John. I've been on a deadline to get this project working on live. There is a weird issue that I want to track down first, where the browser seems to go off into space after the first call to the Web API, with further requests maintaining a status of pending, and never complete. Only seems to happen when calling the Web API - it doesn't happen in your examples. The problem seems to be related to the previous iframes not being removed. I've changed my code to remove them after a short timeout (5 seconds) after the download is complete, but I'm not sure if you want that as part of your code base, as you mention in the comments that problems occasionally occur if you remove the iframes. I need to investigate more, so rather than introduce a possible bug into your library I'll try and solve the issue, and I'll get back to you then.

— Reply to this email directly or view it on GitHub https://github.com/johnculviner/jquery.fileDownload/issues/82#issuecomment-76182822.

[jmayday]

@christhecoder do you mean this particular code?

//has an error occured?
//if neither containers exist below then the file download is occuring on the current window
if (downloadWindow || $iframe) {

    //has an error occured?
    try {

        var formDoc = downloadWindow ? downloadWindow.document : getiframeDocument($iframe);

        if (formDoc && formDoc.body !== null && formDoc.body.innerHTML.length) {

(line 363 in version 1.4.4 of the library).

We've just spotted problem related to this piece of code recently in my team.

Solution is to send some response after reporting failure (adding failure cookie) on server side . It can be as simple as writing some array of bytes to response object. Then formDoc.body.innerHTML is not empty anymore and failCallback gets triggered.

Example for Java: write"ieOnlySpecificsReturnSomethingHere".getBytes() to HttpServletResponse object after setting failure cookie.

[christhecoder]

@jmayday Yes, it was in that section of the code. I made some changes to the code (I don't quite recall whether they actually solved the issue, as there was still outstanding issues from memory), but in any case your solution sounds like the best one.