By the time you read this blog entry, the issue might already be fixed by the Chrome Frame team. Anyways, here’s what we faced:

We recently had a strange issue with some of our users using IE with Chrome Frame to access their intranet application (that was actually a front-end to different other web apps). Some of these apps support Chrome Frame, while others do not. The actual sequence of events happened like this:

1. They opened and logged-in to their home intranet app that did not support Chrome Frame.
2. Then they clicked a link which opened up a pop-up window with the url pointing to another intranet app that supported Chrome Frame.
3. In this pop-up, they clicked a button that opened a new page of the same app in an iframe where the new iframed page also supported Chrome Frame.
4. In this iframed page, they clicked a button that fetched a PDF file from server as an attachment.

The issue we faced were that for all other browsers (even IE without Frame), the attachment was presented for download. However, in Chrome Frame, the attachment just exploded out of the iframe and replaced the page in the pop-up window (from Step 2 above), and the users complained about being shut-out of the application trying to download a file.

Our first attempt for a fix was to try downloading the file in another pop-up window, rather than in an iframe in the same window (of Step 2).

We hit another Chrome Frame hiccup, the newly opened window had a url of the sort:
http://example.com/?attach_external_tab&73104832&5&0&0&600&600

rather than what we wanted (http://localhost/PathToOurPdf.pdf).

Some googling revealed that it was a known issue (see this thread for example). The issue was reported as fixed but we were still experiencing it with the latest Chrome Frame (7.0.517.44 (Official Build 64615)) when this blog post was written.

As I was to loose hope, I got off from my desk for freshing up quickly and an idea crossed my mind (well this has happened soo many times, when you are stuck, leave the issue for sometime, and you would have something that clicks).

I tried the following code:

{syntaxhighlighter brush: jscript;fontsize: 100; first-line: 1; }var win = window.open(“about:blank”, “any unique name here”, “”);
var loc = “Your download file path”;
setTimeout(function() { win.location.href = loc; }, 1000); {/syntaxhighlighter}

and it worked on my dev machine. Basically, to overcome Frame’s issue of opening new windows, I opened a new blank window, waited for sometime to ensure Frame has nothing to do with the new window, and then made it to open our desired path to the pdf.

Happy, I shipped off the update to the client, only to get back a mail in sometime, that nothing happens when they now click the button to download the file. I checked and it was working fine from my system, but was able to verify did not work on theirs (both IE 8).

Arrghhh.. what now, we both had IE 8 with Frame enabled and followed exact same steps (pop-up blocker also was not an issue). Then, I noticed a change in IE settings between our systems.

On my system, I configured IE to always open pop-ups in a new tab, while on theirs, pop-ups were configured to always open in new windows. I changed the setting for pop-ups to open in new windows on my system, and the issue showed up.

Again, just before giving it up, I tried another variation of the above code, and it worked:

{syntaxhighlighter brush: jscript;fontsize: 100; first-line: 1; }var win = window.open(“about:blank”, “any unique name here”, “width=600, height=600”);
var loc = “Your download file path”;
setTimeout(function() { win.location.href = loc; }, 1000); {/syntaxhighlighter}

If you compare both the codes, the only difference you would see is that width and height of the pop-up window have been specified explicitly. I cannot imagine what’s happening between IE, Chrome Frame and the IE setting specified to cause this issue, but hey, it finally worked, and everyone was now happy.

The reason I am posting it here and not submitting an issue at the official Frame bug queue is that we are unable to re-produce the issue outside this particular setup. Even on my machine, if I access the code locally, it works. However, accessing the same code on a remote server fails (which makes me believe it might also be some timing issue with request/response but not sure).

I found a related bug report also here, but that’s marked fixed, and the issue exists for us.