The intricacies of your collection and bindings have introduced a race condition.
The Operation Aborted error is an obscure IE bug, which occurs when the DOM is appended before the page is finished loading.
The Operation Aborted Error
Refer to this question:
What is the Operation Aborted error in Internet Explorer?
This isn't intrinsically an asp.net problem, but, in your case, asp.net is failing to control the order of execution, due to the way you've written the databind. In other words, depending on the order in which resources load and execute (which current is not being controlled), the condition exists.
Incidentally, it may be harder to reproduce the condition in your development environment if you have some of these resources cached on the front end, or if they load more quickly (being available on a local network), which would explain why you're having trouble seeing the error.
The usual pattern for a download-file page (if you must have one; personally I hate them) is either:
<script type="text/javascript">
window.onload= function() {
window.location= document.getElementById('downloadlink').href;
}
</script>
<p>
Your download will begin shortly. If it doesn't,
<a id="downloadlink" href="file.zip">click here</a>.
</p>
Or the same with a meta-refresh instead of the script. Either way should behave pretty much the same.
The meta refresh approach also works, but still the address bar changes to the URL of the file and the underlying window is blank after the file downloads
That shouldn't happen. Is there a version online that can be tested? Normally, when the browser is pushed to a direct file download by any normal method (link click, location.href, meta-refresh), it should keep the previous page on-screen.
the environment doesn't allow me to set headers, so P3P is out
You don't have to use headers to set P3P policies, an HTML <link> tag works just as well:
<link rel="P3Pv1" href="/policy.p3p" />
But why would you need to? If the target URL is just serving a file, there is no need to set a cookie at all, so why bother with P3P?
I'm desperately trying to avoid window.open() to dodge any popup blocker problems
If you window.open() in response to a user click, there are no pop-up blocker problems.
Not that you should need to open a pop-up just to download a file anyway. I am beginning to think there is something highly strange about the file download destination you are linking to — like it's not a file download at all but some kind of odd HTML web app. Linking to a download is not hard, you just link to the file, job done; you seem to be making this much harder than it intrinsically is.
The only usual problem with just linking to a file is that if it contains text, HTML, XML or an image, the browser will display it inline instead of downloading it. The only way to defeat this is using the ‘Content-Disposition: attachment’ header, either by serving it through a script that sets this header, or by configuring your web server to send that header for all file downloads. If you can't do either of those in your server environment, there is no solution.
Best Answer
Check your zone settings for the various users. We had the same trouble and fixed it by adding the site to the trusted zone.