An exotic bug hit my desk today: A business card PDF generation system that I have programmed and maintained for several years refused to cooperate with Internet Explorer 9. It turned out there is a weird bug in the latest IE browser version.
The system creates PDF business cards from database entries and from form data entered in a web page. The PDFs are then sent to a print shop to be batch printed. The code has matured over several years and works flawlessly with all versions of IE, Firefox and Chrome. So I was stunned as I got first reports of failure with IE9.
The analyzes of the problem lead to a JavaScript error when the system tried to reload changes into an iframe on the page (the system uses iframes to present the final PDF files while the user is entering his/her data).
I found that the following code line that updates the iframe document threw the error:
parent.frames["bizCardFront"].location.href = "newpdf_url.pdf";
Funny enough this line worked once when it was executed for the very first time, loading the initial PDF into the iframe. But it failed on every following update of the PDF document.
Further analyzes showed that the location property of the frames document was damaged after the first PDF had been loaded into the iframe. The IE9 script debugger showed the location property (along with many others) to expose an error type and the value “Invalid calling object” instead of showing its correct content. This happened no matter if the first document load was done by JavaScript or by an HTML src attribute in the original iframe definition.
As this is a productive system that is constantly used I urgently had to find a solution. I tested alternatives and was happy to finally find one that worked in IE9. Instead of using the location.href attribute of the frame document, I access the frame’s DOM node with getElementById() and alter its src attribute like this:
document.getElementById("bizCardFrontID").src = "newpdf_url.pdf";
This solution works for IE7, 8, 9 and all current versions of Firefox and Chrome.
how is that a BUG? – its part of the cross browser issues…
It has nothing to do with cross browser problems.
A part of the IE DOM is lost if a PDF document is loaded into an IFrame twice.
You used was the same iframe?
Yes. I used ONE Iframe in my page and reloaded its document when the content of a form in the parent page was changed by the user.
i use the iframe.src to show the pdf document and i use the document.location.href to download it.
if the document is opened by another iframe then the document.location.href cause the lose of pdf displayed in the first iframe.
Hi Tarek,
is your download invoked by the user clicking some link or button?
If so then I would try the following approach: Instead of using
document.location.href
to download the PDF you could use a normal<a href="...">
link and update its href attribute on click by JavaScript to contain the correct PDF download address. I suppose this would work.As someone wrote in another forum:
“In IE9, the frame object is replaced by some PDF object that doesn’t contain the location object. So the second time you cannot update the frame url with location.”
Another work-around is to use window.open()
Example:
window.open(’1.pdf’, ‘otherframe’);
Thank you, Jörg Wagner!
We were facing the same issue and used your suggestion with success