Form with target="_blank" behavior changed in IE 9 and 10

Question

I have an app that uses something like the following code to open a dynamically generated report in a new tab. (I've mocked out the parameters for the sake of a demo.)

function gblPDFWdw(pdf) {
    var formDiv = document.createElement("div");
    formDiv.innerHTML = "<form method=post action='" + pdf + "' target='_blank'><input type=hidden id=test name=test value='test'></form>";
    var form = formDiv.firstChild;
    document.body.appendChild(form);
    form.submit();
    form.parentNode.removeChild(form);
}

The pdf parameter us just the URL to the script that generates the PDF. The reason for the form manipulation is to get the parameters POSTed to the script rather than as GET parameters.

In IE 8 and below, Chrome, Firefox, etc., this will do one of two things:

1. If the browser can read PDFs (via built-in functionality or a plugin), it will open a new tab with the report, which is the desired behavior.
2. If the browser can't read PDFs, it will open the new tab, immediately close it, and download the file.

It seems that #2 has changed in IE 9 and above. It will open a new tab, but it yields only a blank screen until the user goes back to the original tab, clicks "Open" or "Save", and then the PDF downloads as expected. It's a very confusing interface.

I suppose one way to work around this would be to generate a temporary PDF file, and then simply window.open() to it. Are there other ways to tweak the behavior of this functionality? Or is there a recommended practice that I've not run across?

(Note: This isn't at all PDF specific; any file that the browser may download instead of display natively seems to be problematic.)

EDIT: Looks like I'm further behind the curve than I realized. It appears that this also occurs in IE9, and I'd never noticed as I never tried it without the PDF plugin installed or with another file type.

Interestingly, the above code works like I'd expect if I remove the input field from the form. I'm not sure why the browser would treat that any differently. Of course, in my case, I need the input to POST data to my script.

EDIT 2: Silly mistake. input is self-closing. Fixed.

EDIT 3: Here are some screenshots to better explain the issue. I'm using this JSBin for testing. I have an onclick event to trigger the Javascript function above.

The process starts on the first tab.

Then, once you click the text, a new tab opens. But it's blank!

And it turns out that the original (now hidden) tab has a message asking whether to open or save the file.

Clicking "Open" or "Save" will open the file just fine. But the process is terribly confusing, and inconsistent with other browsers.

EDIT 3: One step forward, one back. If I use window.open() to create a new window, and then programmatically set the form.target to the name of that window, I can at least get the Open/Save message in the opened tab…though I'd much prefer it to immediately close the tab like other browsers. Worse, with that technique, the new tab no longer immediately closes. Perhaps there's another technique?

Answer 1

One off-shot solution would be to detect IE and PDF plugin avaliability and then set 'target' attribute to '_self' in (>IE9 && !plugin) situation. I've found PluginDetect which claims AdobeReader plugin detection.

All in all it is fairly ugly and unreliable method but should give result in some cases.