L
Lou Zher
IE/Adobe developers,
I ran into this problem a while ago, and I have a couple of recommended
solutions. I'm posting this as a public service as well as having these
notes handy from anywhere via Deja, but mostly I was hoping to elicit some
suggestions from the community as to how the solutions worked for them and
any better methods you've found.
*** Problem Definition:
On certain installations of IE & Acrobat Reader or Full version navigating
away from a previously loaded PDF in a frame or iframe to an HTML page may
cause a keyboard focus problem.
The problem has been reproduced with IE6 and Reader 5, 5.1 and Acrobat 5.
The focus problem causes tab, backspace, delete and some other keys to not
behave properly.
Reproduce the problem:
The simplest way to test for this problem is to build a pair of test pages
like these:
<!--test.htm-->
<html>
<body>
<a href=test2.htm target=x>test2</a>
<br>
<iframe name=x frameborder=0 height="100%" width="100%">
</body>
</html>
<!--test2.htm-->
<html>
<body>
<input type=text>
<a href=test.pdf>test.pdf</a>
</body>
</html>
and put a pdf called test.pdf in the same folder.
Now load test.htm in your browser, click the link "test2", then click the
link inside called "test.pdf", then click the "test2" link again, now click
inside the text box, type something and hit backspace. Did you jump back to
the pdf? That's the problem! To get around this problem, the user can hit
the tab key after clicking the "test" link the second time and once they tab
past the last focusable element of the master page, the problem goes away.
What is the source of the problem:
I can only hypothesize about the core reason for the problem. I don't
believe that this is Adobe's fault, but rather a problem with IE and its
handling of framed plugins. While this doesn't seem to occur with the
Word/IE plugin, that just may be because Microsoft put a workaround directly
in the plugin which means Adobe could too. In fact, they may have already
since I could not reproduce the problem using Reader 6.
*** Solution #1: Reload the whole page when navigating away from a PDF
How do I get around this problem? One way is to make the outside link reload
the whole page, although this is less than ideal. (This seems to be the
solution nature.com used to get around this problem.)
*** Solution #2: Leave FRAMEBORDER on and optionally try to hide most of it
Another way I have found to get around this problem is to leave the frame
border on. This is not a very attractive solution, however, one can position
the IFRAME absolute with just enough negative offset to hide part of the
border and use the IFRAME's onload and the document BODY's onresize events
to dynamically resize the IFRAME to hide more of the border to space beyond
the current view.
Here's a sample:
<!--test.htm-->
<html>
<head>
<script language=Javascript>
function y() {
var o=document.getElementById("x");
o.style.width=document.body.clientWidth+4;
o.style.height=document.body.clientHeight-o.offsetTop;
}
</script>
</head>
<body scroll=no style="margin:0px;" onresize='y();' onload='y();'>
<a href=test2.htm target=x>test2</a>
<br>
<iframe name=x id=x style="position:absolute; left=-2px;">
</body>
</html>
In this case, only the top part of the border remains visible. No too bad.
Turning on the frameborder to avoid this problem would seem to suggest that
IE handles multidocument tabbing based partially on their having visible
attributes and that a borderless frame while the plugin is either active or
being unloaded has no visible attributes. This seems to be due, in part, to
the application/pdf mime type handling that goes on inside IE.
*** Solution #3: IFRAME loads a page with EMBED element
Another method for getting around this problem is to not load PDFs directly,
but to reference a document that includes the EMBED element to get the PDF.
The disadvantage is that you cannot use the framename.print(); method to
invoke Adobe's print function, as it is not exposed at this level. You could
capture the onbeforeprint event to chain to this event, however, you cannot
stop IE's print dialog from appearing as well. You would have to reference
the EMBED element's print function to print, giving the EMBED an ID and
..print() on that.
Here's a sample of using EMBED:
<!--testembed.htm-->
<html>
<body style="margin:0px;" scroll=no>
<embed id=e src=test.pdf width="100%" height="100%" type=application/pdf
fullscreen="yes">
</body>
</html>
So instead of referencing the PDF directly, you would reference a page that
generates the above with embed's src= pointing the real PDF. Printing from
outside the IFRAME can be done by [iframeid].[embedid].print(); in this case
x.e.print();
Presumably, this print issue is not a big one unless you are turning off the
toolbar in the plugin, preventing the user from selecting Adobe's print
button.
This solution is not very practical if you already have a zillion pages and
couldn't go through and retarget .pdf hrefs to use this dynamic embed page
generator, but you could make it work by making a very clever filter on the
web server. It could intercept requests for .pdf and instead return the
text/html content unless the referer http header tag is the same as the .pdf
being requested, in which case it just returns the .pdf.
Another quirk (perhaps an advantage, perhaps not) of this solution is that
it makes it much more difficult for a user to right-click "Save Target
As..." on a PDF since doing that would just save the text/html content.
I ran into this problem a while ago, and I have a couple of recommended
solutions. I'm posting this as a public service as well as having these
notes handy from anywhere via Deja, but mostly I was hoping to elicit some
suggestions from the community as to how the solutions worked for them and
any better methods you've found.
*** Problem Definition:
On certain installations of IE & Acrobat Reader or Full version navigating
away from a previously loaded PDF in a frame or iframe to an HTML page may
cause a keyboard focus problem.
The problem has been reproduced with IE6 and Reader 5, 5.1 and Acrobat 5.
The focus problem causes tab, backspace, delete and some other keys to not
behave properly.
Reproduce the problem:
The simplest way to test for this problem is to build a pair of test pages
like these:
<!--test.htm-->
<html>
<body>
<a href=test2.htm target=x>test2</a>
<br>
<iframe name=x frameborder=0 height="100%" width="100%">
</body>
</html>
<!--test2.htm-->
<html>
<body>
<input type=text>
<a href=test.pdf>test.pdf</a>
</body>
</html>
and put a pdf called test.pdf in the same folder.
Now load test.htm in your browser, click the link "test2", then click the
link inside called "test.pdf", then click the "test2" link again, now click
inside the text box, type something and hit backspace. Did you jump back to
the pdf? That's the problem! To get around this problem, the user can hit
the tab key after clicking the "test" link the second time and once they tab
past the last focusable element of the master page, the problem goes away.
What is the source of the problem:
I can only hypothesize about the core reason for the problem. I don't
believe that this is Adobe's fault, but rather a problem with IE and its
handling of framed plugins. While this doesn't seem to occur with the
Word/IE plugin, that just may be because Microsoft put a workaround directly
in the plugin which means Adobe could too. In fact, they may have already
since I could not reproduce the problem using Reader 6.
*** Solution #1: Reload the whole page when navigating away from a PDF
How do I get around this problem? One way is to make the outside link reload
the whole page, although this is less than ideal. (This seems to be the
solution nature.com used to get around this problem.)
*** Solution #2: Leave FRAMEBORDER on and optionally try to hide most of it
Another way I have found to get around this problem is to leave the frame
border on. This is not a very attractive solution, however, one can position
the IFRAME absolute with just enough negative offset to hide part of the
border and use the IFRAME's onload and the document BODY's onresize events
to dynamically resize the IFRAME to hide more of the border to space beyond
the current view.
Here's a sample:
<!--test.htm-->
<html>
<head>
<script language=Javascript>
function y() {
var o=document.getElementById("x");
o.style.width=document.body.clientWidth+4;
o.style.height=document.body.clientHeight-o.offsetTop;
}
</script>
</head>
<body scroll=no style="margin:0px;" onresize='y();' onload='y();'>
<a href=test2.htm target=x>test2</a>
<br>
<iframe name=x id=x style="position:absolute; left=-2px;">
</body>
</html>
In this case, only the top part of the border remains visible. No too bad.
Turning on the frameborder to avoid this problem would seem to suggest that
IE handles multidocument tabbing based partially on their having visible
attributes and that a borderless frame while the plugin is either active or
being unloaded has no visible attributes. This seems to be due, in part, to
the application/pdf mime type handling that goes on inside IE.
*** Solution #3: IFRAME loads a page with EMBED element
Another method for getting around this problem is to not load PDFs directly,
but to reference a document that includes the EMBED element to get the PDF.
The disadvantage is that you cannot use the framename.print(); method to
invoke Adobe's print function, as it is not exposed at this level. You could
capture the onbeforeprint event to chain to this event, however, you cannot
stop IE's print dialog from appearing as well. You would have to reference
the EMBED element's print function to print, giving the EMBED an ID and
..print() on that.
Here's a sample of using EMBED:
<!--testembed.htm-->
<html>
<body style="margin:0px;" scroll=no>
<embed id=e src=test.pdf width="100%" height="100%" type=application/pdf
fullscreen="yes">
</body>
</html>
So instead of referencing the PDF directly, you would reference a page that
generates the above with embed's src= pointing the real PDF. Printing from
outside the IFRAME can be done by [iframeid].[embedid].print(); in this case
x.e.print();
Presumably, this print issue is not a big one unless you are turning off the
toolbar in the plugin, preventing the user from selecting Adobe's print
button.
This solution is not very practical if you already have a zillion pages and
couldn't go through and retarget .pdf hrefs to use this dynamic embed page
generator, but you could make it work by making a very clever filter on the
web server. It could intercept requests for .pdf and instead return the
text/html content unless the referer http header tag is the same as the .pdf
being requested, in which case it just returns the .pdf.
Another quirk (perhaps an advantage, perhaps not) of this solution is that
it makes it much more difficult for a user to right-click "Save Target
As..." on a PDF since doing that would just save the text/html content.