If a browser has a built-in PDF capability but does not have "application/pdf" in the mimetypes array (ie. does not require a PDF reader plugin), then PluginDetect will have to use the 'empty.pdf' file to perform "not on the fly" (NOTF) detection. The disadvantage for this particular browser is that PluginDetect must wait for the browser window to fully load before it can determine that the browser is PDF capable. This may be a problem if you have some large images in the same web page that take a long time to download from the server.

One way around this problem is to place the PluginDetect script and the PDF detection code inside a frame. PluginDetect would thus only need to wait for the frame to fully load. The PDF detector at the top of this page, for example, uses an iframe. Feel free to look at the source code. :-)



A few issues to note with this technique:

1) Some versions of the Chrome browser do not allow scripting across frames in a local web page. However, this is not an issue when the page is on a web server. This appears to be an overly strict default security setting for Chrome.

2) The iframe is not compatible with HTML 4.01 Strict doctype and XHTML 1.0 Strict doctype. So you may want to use the Transitional doctype for HTML 4.01 or XHTML 1.0. On the other hand, the iframe is part of the HTML 5 specification. You could also just use frames instead of iframes.

3) Some browsers may not allow the iframe to fire it's "window.onload" event way ahead of the parent page firing it's "window.onload" event. In such cases, the iframe technique presented here offers no speed advantages for PDF detection.

4) If using frames/iframes is unacceptable to the user, then you will have to make sure that the web page containing PluginDetect can load quickly enough so that PDF detection is performed in a timely manner.