In IE with Chrome Frame, after clicking link for file attachment, Javascript blocked

Question

Here's a strange one. Throwing it out there to see if anyone has any thoughts.

This problem only occurs with IE when Chrome Frame is installed. Appears to affect all version of IE.

When a user downloads a file, the app stops responding (the file is successfully downloaded). Links still work, but all JS appears to be blocked. If the user re-loads the browser, the app works fine, and re-downloading (even the same file) no longer causes the app to hang.

Here is an example link (just totally vanilla):

<a id="m2658941440_a0_1316118824779" href="getAttachment.do?messageId=2658941440&amp;attachmentId=0&amp;preventCache=1316118825309" class="attachment" _dijitmenudijit_menu_7="1">attachment_prob.txt (277 bytes)</a>

And here is the request and response as reported by Fiddler.

REQUEST:

GET https://www.foo.net/getAttachment.do?messageId=2658941440&attachmentId=0&preventCache=1316122999730 HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Referer: https://www.foo.net/main.do
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; chromeframe/13.0.782.220)
Accept-Encoding: gzip, deflate
Host: www.foo.net
Connection: Keep-Alive
Cookie: __utma=185983734.639214142.1315756824.1316118759.1316121566.5; __utmb=185983734.2.10.1316121566; __utmz=185983734.1315756824.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmc=185983734; fooDomain=foo.net; isYtBlocked=true; TIME$STATE=10ba57c6bdb0075922b4c9ad4ef9940baf6bde26c79f3c6bcfe700413fe1710e; xgh=gnweb10; JSESSIONID=8487D0FE3D31EE81D2DE4E0BD19B7104; BIGipCookie=000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000; cdnPath="https://cdn.foo.net"; SESSION$STATE=10ba57c6bdb0075922b4c9ad4ef9940baf6bde26c79f3c6bcfe700413fe1710e; JID=mtyson; XMPPTOKEN=4662e808-1492-45ff-9aa7-ca39969574ea; contest-data=null; Foo.web3.foo.net.-csdvew.86158rid=5648145; PHPSESSID=cfepc8dnvmj94tbrqb8nbb03r0; Foo.web3.foo.net.-csdvew.86158sid=7ff697be-0d55-40c7-bb4a-f896443b22c3

RESPONSE:

HTTP/1.1 200 OK
Date: Thu, 15 Sep 2011 21:43:32 GMT
Server: Apache/2.2.10 (Fedora)
Content-Disposition: attachment; filename="attachment_prob.txt"
Cache-Control: max-age=2
Expires: Thu, 15 Sep 2011 21:43:34 GMT
Set-Cookie: xgh=gnweb10; path=/;
Set-Cookie: BIGipCookie=000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Vary: User-Agent,Accept-Encoding
P3P: policyref=http://www.foo.net/w3c/p3p.xml, CP=ALL
Connection: close
Content-Type: text/plain; name=attachment_prob.txt;charset=us-ascii
Content-Length: 277

https://www.foo.net/messages.do?op=messageDetail&userId=12735728&messageId=2620253518&owner=true

select groupid, shardid from users where userid=12735728;
+---------+---------+
| groupid | shardid |
+---------+---------+
|   57826 |       2 |
+---------+---------+

UPDATE 1 Turns out ANYTHING that returns a download will cause the problem. So even:

<a id="m2658941440_a0_1316118824779" href="http://download.mozilla.org/?product=firefox-6.0.2&os=win&lang=en-US" class="attachment" _dijitmenudijit_menu_7="1">attachment_prob.txt (277 bytes)</a>

Produces the problem.

But

<a id="m2658941440_a0_1316118824779" href="http://www.google.com" class="attachment" _dijitmenudijit_menu_7="1">attachment_prob.txt (277 bytes)</a>

does NOT.

Update 2 Based on gilly3's comment, if the target is set to _blank, the file will download ok in a new tab, without breaking JS on main page.

I tried pointing the target to an iframe in the main page, but the problem does present in that case.

Answer 1

I worked around this by programatically creating an Iframe, and settings its url to the file download, instead of using the current window. That fixed this.

I noticed with the way it was broken, it was using the IE downloader (despite it being chromeframe). When I use the iframe, it uses the chrome downloader.