Here is the changelog for the PluginDetect Library.


PluginDetect v0.9.1 (1/4/2016)

[Microsoft Edge] Browser detection for the Microsoft Edge browser has been added. We have added PluginDetect.browser.isEdge and PluginDetect.browser.verEdgeHTML properties to the PluginDetect library. Note that we detect the version of the Edge HTML layout engine, and not the version of the Edge browser app itelf. At the moment, it does not look like the app version iteself is easily detectable via Javascript.

[Flash] Small update to Flash detection. Flash version numbers have the format of "Major,Minor,Release,Build". PluginDetect can now get the Build # for a few additional browsers on Windows using only passive plugin detection methods. However, for Chrome we still cannot get the Build # using passive methods only. We would have to set the "instantiate" input argument to "true" in order to get the Build # for Chrome.
   We also added the ability to know the precision of the detected plugin version using PluginDetect.getInfo("Flash"). This way, when the Build # is "0" in the detected plugin version, you'll know if it was actually detected as being 0 or if the Build # simply could not be detected at all.

[Java] Updated the Java applet to version 5.3. Also a few other changes to Java detection in the PluginDetect library.

[AdobeReader] The format for the version numbers has changed slightly for Adobe Reader 15+ when querying the Adobe Reader Javascript. We had to update the library to account for this format change. This change only affects plugin detection for Internet Explorer.



PluginDetect v0.9.0 (04/13/2015)

[ ] The PluginDetect Library no longer needs to wait for the window.onload event to fire in order to show detection results for PDFReader, PDFjs, or Java. Detection results are now completely independent of the browser window load times.
   As a consequence of this, you are now free to load the PluginDetect Library in any number of ways. You can place the <script> tag that loads the Library into the document <head>, or in the document <body>. You may also use Javascript to dynamically load the Library if you wish (ie. Javascript creates a <script> element, and places it in the DOM somewhere to load the Library. Just make sure you wait long enough for the script to load before performing plugin detection).

[Adobe Reader] As of Adobe Reader 10, it was no longer possible to detect the 3rd digit of the plugin version using the GetVersions( ) method for Internet Explorer. So, we could only get the version in the format of A,B,0,0.
   PluginDetect now uses an additional method of detection to get the 3rd digit for IE, but only for Adobe Reader 11 and higher. This method assumes that Javascript within Adobe Reader is enabled. The detected plugin version for IE will thus have the format A,B,C,0.

[PDF Reader] PDF Reader detection stopped working for Safari on iOS 8. It turns out that there is a bug in iOS 8 where pdf documents cannot be displayed using <object>/<embed> tags. A workaround has been found and detection now works for iOS 8.



PluginDetect v0.8.9 (1/21/2015)

[Download page] I had to stop using the Google Closure Compiler to minify PluginDetect. It rewrites code, that could interfere with the script customization on the download page. So, we use the Yui minifier once again. However, one can still use the closure compiler AFTER the script has been customized and saved from the download page.

[Adobe Reader] Small bugfix.

[Adobe Reader] There is a bug with Adobe Reader itself. For IE 11/ Win 7, it is possible that the Adobe Reader will switch from displaying PDFs in the browser to displaying in the Adobe standalone application, without the user telling it to do so. This appears to sometimes occur when the ActiveX plugin is run in the browser (ie. trying to display a PDF in an <object>/<embed> tag, or using new ActiveXObject("...") ). Adobe needs to fix this.

[Java] Small bugfix.

[Java] We have a new version (v 5.2) of the getJavaInfo.jar applet. The applet is sometimes used to assist in Java plugin detection. The only real change here is that we are now using a manifest in our jar. You can get the applet from the download page.

[Download page] We added the option to the download page to remove ActiveX plugin detection from the Library. This will make your customized script smaller if you are only doing detection on non-ActiveX based browsers.
   If you remove ActiveX detection, then the following Library properties will be undefined:
PluginDetect.browser.ActiveXEnabled, PluginDetect.browser.ActiveXFilteringEnabled, PluginDetect.getInfo("Java").objectTagActiveX, PluginDetect.getInfo("WindowsMediaPlayer").ActiveXPlugin.

[jshint] Started using jshint to check our script library.

[QuickTime] Updated QuickTime detection. The detector now allows the user to decide whether to detect the genuine QuickTime plugin, and/or 3rd party QuickTime media players.


[Internet Explorer] As of September 2014, the behavior of Internet Explorer has changed. Internet Explorer will no longer allow certain outdated ActiveX controls to run. They call this out-of-date ActiveX blocking. At the moment, Internet Explorer will block outdated Java controls, and in the future it will block other outdated plugins as well.
   This new behaviour will slow down the spread of Java based malware. Unfortunately for us, it means that when PluginDetect tries to detect an outdated Java plugin, then IE may give a popup message asking for permission to run/update that plugin.




PluginDetect v0.8.8 (7/21/2014)

[Bugfix] Fixed a bug on the download page. Some of the checkboxes would not uncheck themselves when you reloaded the page.

[ ] The source code for this library has been released. It can be found on the download page. Please note: the core of the Library (which is common to all plugin detection modules) is still likely to undergo some changes.

[ ] The overall structure of the library has been modified. It is now encapsulated in an anonymous function. This permits the library to be a bit smaller and simplified in some ways.
   As a result of these changes, the yui minifier started to behave in ways I did not like. It no longer minified certain variables. So, I switched over to Google's Closure Compiler.
   The Closure Compiler is more agressive in minification, which is good but this is also a bit more risky (since the download page chops up the script into pieces for script customization). The code execution order is still maintained with this compiler, but they do rewrite some of the code (in addition to using shorter variable names). As a result of this, we had to add some code to the download page to make sure that everything was ok.

[ ] Tested PluginDetect on Win7/Java 7u55 (32 bit), Win7/Java 8 (32 bit), Win7/Java 8u5 (32 bit), Linux/Java 8u5 (32 bit), Win7/RealPlayer 17 (32 bit), Win8/Java 8u11 (32 bit).

[Java/VLC/QuickTime] Another small update so that plugin detection is somewhat less dependent on browser detection.

[Java bugfix] When the Java Deployment Toolkit is disabled, but the Java update is > 64 (ie. Java 7u65, Java 7u66, Java 8u70, etc...) then the detected Java version would be incorrect. The issue has been corrected.

[Opera] The Opera browser (for version 15 and higher) has changed its userAgent. PluginDetect had to be updated to detect the browser. Also, PluginDetect.browser.verOpera is now a string instead of a number.



PluginDetect v0.8.7 (2/25/2014)

[Firefox 28+] A future release of the Firefox browser will no longer allow Javascript to enumerate all items in the navigator.plugins and navigator.mimeTypes arrays. This change appears to be due to privacy concerns. In anticipation of this browser behavior change, the PluginDetect Library has been modified. This affects ALL plugins handled by PluginDetect.
   This update is critical. Older versions of the Library should no longer be used for Firefox 28+, or any other browser that forbids navigator.plugins enumeration.


[Internet Explorer 11] PluginDetect should be fully compatible with IE 11 now. It is interesting to note that IE 11+ is trying to start behaving more like other browsers now.
   For example, the "readyState" property has been removed from most HTML tags. Also, typeof window.ActiveXObject == "undefined". And the navigator.plugins and the navigator.mimeTypes arrays can now be populated, but only if the plugin installers put the appropriate info into the registry to take advantage of IE 11's new capabilities.
   Perhaps one reason for this change is the fact that Internet Explorer is no longer the dominant browser out there.

[Feature detection] Because of the recent changes to Firefox and Internet Explorer, and because of the increasing number of platforms & browsers that appear on the marketplace every year, we are now attempting to make plugin detection in this Library as independent from browser/platform type as possible. These changes will be ongoing.
   This is important, because browser detection code often depends on certain assumptions, such as looking at the navigator.userAgent. And the user agent can easily be modified by the end user or the browser vendors.

[Internet Explorer] The generic ActiveX detection method now stores any instantiated plugins in memory, instead of just immediately trying to delete them. The plugins are deleted from any Javascript variables/DOM using a cleanup routine as the window unloads.

 

[ ] PluginDetect.beforeInstantiate( ) method has been renamed to PluginDetect.onBeforeInstantiate( ).


[ ] PluginDetect.getInfo( ) will now return null if there is no info available. Otherwise, it returns an object{ }.

[ ] After the web page has fully loaded, and all plugin detections have been completed, the <div id="plugindetect"></div> will now REMAIN IN THE DOM. Hence you no longer need to specify class="doNotRemove" in the <div>.
   This change allows any instantiated plugins to remain in memory until the page unloads. If a user gave security permission to start up a particular plugin during detection, he may not have to give permission again when instantiating that plugin a second time (using the same HTML tag) in that same web page. This change is merely a precaution against something that may or may not actually happen, depending on the browser and/or plugin.
   Also, if you specify your own <div id="plugindetect"></div> in the web page, then PluginDetect will no longer set any of its css properties. However, it should usually not be necessary for the user to specify this <div>, since PluginDetect automatically generates the <div> when needed.
   In either case, this <div> is removed from the DOM right before the web page unloads.


[Security popups] The trend for many browsers these days has been to request user permission before running an outdated plugin (for reasons of security). Due to this trend in Firefox/Chrome, etc..., a number of plugin detection modules have been rewritten so as to do passive plugin detection by default. This way we can often avoid these popups. The default can be overridden using the appropriate PluginDetect input arguments.

[Java] From now on, the Deployment Toolkit will not run (by default) for non-IE browsers to obtain the Java version. Chrome/Firefox do not allow the Tookit plugin to run anyway when it is outdated, so there usually is no point. This will reduce the chances of the user seeing some kind of security/update popup when doing Java detection. [If you want to force the Toolkit to run then you can still use the getDeploymentToolkitObj( ) method.]
   We still allow the Tookit to run for IE, however, because no matter what detection methods we use, some kind of popup can occur when Java is outdated. I am still waiting for Java to take advantage of IE 11's ability to have a plugin appear in the navigator.plugins array. When this happens, Java detection should be silent in IE and not create any nagging popups when the plugin is slightly out of date.


[Flash] Detection code has been rewritten. The Flash player will no longer run by default for non-IE browsers just to get the full Flash version. The reason is that some browsers may give a security popup message when you try to run an outdated player. If you want to force the player to run to get the full version, you will have to use the "instantiate" input argument to the getVersion( ) and isMinVersion( ) methods.

[RealPlayer] Detection code has been rewritten. By default, the plugin will not be instantiated for non-IE browsers simply to get the plugin version. You will need to specify if you want to instantiate via the "instantiate" input argument.

 

[Silverlight] Detection code has been rewritten.

 

[Windows Media Player] Detection code has been rewritten. By default, the plugin will not be instantiated for non-IE browsers simply to get the plugin version. You will need to specify if you want to instantiate via the "instantiate" input argument.

[ ] I would have liked to do alot more, but the release of Firefox 28 is just around the corner. So, here we are. :-)



PluginDetect v0.8.6 (11/24/2013)

[Internet Explorer] When IE is in Quirks mode (ie. when there is no doctype specified in the web page for IE 10, 9, and 8), and the "Use better Internet Explorer version detection" option was NOT selected when generating the PluginDetect script, then $.browser.verIE incorrectly would be set to 5. This caused issues in certain cases for Java/QuickTime/VLC/ActiveX detection. This issue has now been resolved.

[Java, Deployment Toolkit plugin] Small bugfix for Java detection. The Deployment Toolkit was not being queried for the Java version for IE when $.browser.verIE < 6. This restriction has been removed, since it does not make sense to check the IE version when attempting to run the toolkit plugin. The toolkit will never be found in IE < 6 anyway. And it is always (remotely) possible that $.browser.verIE has an incorrect value, which might have prevented the toolkit from running.

[Java, IE 11, Bugfix] In NOTF Java detection, I have seen cases where querying an applet right after window.onload can sometimes fail. While the Java applet will have been fully downloaded, the Java/Javascript bridge may not be completely ready for querying. This may possibly be a browser/Java bug of some sort. This issue has been resolved.

[ ] The manner in which instantiated plugins are removed from the DOM has been modified for greater reliability.



PluginDetect v0.8.5 (9/28/2013)

[Browser detection] Browser detection results are now stored in the PluginDetect.browser{ } object.
So PluginDetect.isIE would become PluginDetect.browser.isIE
PluginDetect.verIE becomes PluginDetect.browser.verIE
etc...

[PDF.js/Firefox] The old method of detecting PDF.js stopped working for Firefox 24+. As I had feared, the detection method used was too brittle. PluginDetect now uses another method to detect PDF.js on Firefox. (Mozilla still has not given us any official way to identify PDF.js in Firefox, which is why any detection method we use will be considered brittle).

[DummyPDF] A new version of the DummyPDF (empty.pdf, 1058 bytes, PDF 1.4) has been released. The DummyPDF is used for PDFReader and PDF.js detection. The old empty.pdf could sometimes cause a popup in PDF.js in Firefox, saying "This PDF document might not be displayed correctly". I believe this is due to the text/fonts contained within the PDF. For this reason, the new DummyPDF contains no text/fonts at all. It only contains a small image.

[Internet Explorer] It appears that IE 11 breaks our browser detection code, because conditional compilation is no longer supported in IE 11+. Conditional compilation in IE 11 only works in Compatibility Mode. So, we modified our IE detection code.




PluginDetect v0.8.4 (9/10/2013)

[Windows Media Player] Detection module for WMP has been rewritten. We can once again detect the plugin version (via the WMP Firefox plugin) for Chrome without triggering any security popups. Previously, we avoided getting the plugin version on Chrome because an old version of that browser would give a popup.
   We also no longer try to detect when a 3rd party player hijacks a WMP mimetype. Many browsers do not provide reliable enough info on when a mimetype is hijacked, so we don't bother to try to detect this. I do not believe there is any web standard for browsers to let web devs know when a mimetype has been hijacked.



PluginDetect v0.8.3 (8/8/2013)

[VLC] For VLC Player 2.0.7, the ActiveX control does not give the plugin version. This could perhaps be a VLC bug. Thus, we added a method of detection to get the plugin version.

[ ] The PluginDetect <div>, when specified by the user, now allows the user to add a class="doNotRemove", so that the <div> will not be deleted from the page. By default, the PluginDetect div (<div id="plugindetect"></div>) is normally removed from the web page when plugin detection is completed. We also fixed a bug so the <div> is properly initialized/styled, even when it is not
used for plugin detection.

[Java bugfix] Java detection had the ability to take focus away from any input fields in a web page. This issue has been fixed.

[Java bugfix] When ActiveX is disabled, Java detection for the <applet> tag during NOTF detection would not work. This issue has been fixed.

[ActiveX] We added a generic ActiveX detector for Internet Explorer. You specify the classid for an ActiveX control/plugin/addon, and the detector will return the status and version.

[IE component] We added a generic component detector for Internet Explorer. Based on clientCaps.

[Internet Explorer] PluginDetect.verIEfull has been renamed to PluginDetect.verIEtrue. This parameter depends on clientCaps. Previously, I believed that clientCaps only worked for 32 bit Windows, based on my misinterpretation of Microsoft documentation. However, I now believe that clientCaps does indeed work for 64 bit Windows as well. It is only a matter of supplying the right classid(s) to get the IE version.

[Internet Explorer] Also, we note that the user agent for the upcoming Internet Explorer 11 appears to have changed. Instead of "MSIE 11.0" the user agent will (or may) simply have "IE 11.0". PluginDetect has been updated to reflect this change.



PluginDetect v0.8.2 (6/25/2013)

[Java] We removed the Java NOTF checkbox from the download page menu. From now on, your PluginDetect script for Java will automatically be capable of both OTF and NOTF Java detection. This makes the Library easier to maintain. Also, it's easier when having to submit the script to an AntiVirus whitelist, because now there are fewer script permutations that have to be submitted.

[Java] Version 5.1 of the getJavaInfo.jar applet has been released. When the width and height of the applet are sufficiently large, the applet will now display the Java version and the Java vendor. This is useful as visual confirmation that Java is running. It is also useful when trying to verify that the jarfile input argument path/name were correctly specified. (During the normal course of plugin detection, however, the Java applet will be no larger than 1 x 1, and so the applet will not visually display any info in that case. Instead, PluginDetect can query the applet to get any Java information.)

[Java] The Deployment Toolkit is no longer the first detection method used for Java detection on non-Internet Explorer browsers. Instead, one or more traditional methods (using the navigator arrays) will be used first, and then the Toolkit. We changed this order because the Toolkit from Oracle can sometimes generate an annoying popup whenever your Java is out of date. This change will reduce the likelihood of such a popup from occuring during Java detection.
   I would have much preferred to continue to use the Toolkit as the first and primary means of Java detection for non-IE browsers, since it gives a quick and reliable method of Java detection. Unfortunately, these Java security popups are getting to be too much to tolerate. Hence the change. As for Internet Explorer, there does not appear (yet) to be any way to avoid the security popups generated by the Java runtime or the Java Deployment Toolkit. Internet Explorer is in a class by itself, as usual.

[Java] We updated the code used to verify the jarfile path/name. The Java applets are now displayed to provide visual confirmation that Java is running and that the jarfile path/name are correct.
   Previously, we only provided nonvisual confirmation. But the drawback is that this relies on the Java/Javascript bridge, and the bridge may not always work.

[Java] We no longer use the Liveconnect method window.java.lang.System.getProperty("...") to get the Java version. There are 4 reasons for this:
   1) As of Java JRE 6u10, the global window.java object was DEPRECATED by Oracle/Sun.
   2) Opera was one of the browsers that used the window.java object, but Opera 10.5+ no longer supports this feature.
   3) Gecko was the other browser type that used the window.java object, but support has been discontinued as of Firefox 16+.
   4) Removal of this code simplifies PluginDetect and makes it smaller by ~1300 bytes.

[Java] The per-applet "Packages" keyword no longer works as of Java 1,7,0,21+. We used the Packages keyword together with a running Java applet to help us determine when Java Plugin2 was active, since the Packages keyword was introduced along with the Next Generation Java Plugin. We now fall back on our other methods to determine Plugin2 status. (Is there an applet based method that can be used to detect Plugin2 status?)

[PDF.js] Added the ability to verify the DummyPDF [path/]name for this Firefox plugin.



PluginDetect v0.8.1 (4/11/2013)

[Firefox PDF Viewer] We added the ability to detect the native PDF viewer in Firefox.

[Chrome] The Chrome browser is now detected on iOS.

[Bugfix] A significant bug has been fixed for the Generic PDF Reader detector. This issue affects Chrome, Safari Desktop (Windows and Mac), and Safari/iPad. This bug ended up making Safari give an incorrect result for the Generic PDF Reader detection. This issue is now fixed.

[Internet Explorer, clientCaps] It appears that clientCaps in IE only works for 32 bit Windows, and not 64 bit Windows. This means that PluginDetect.verIEfull will only have a value for 32 bit Windows. There is perhaps another way of detecting the Internet Explorer version on 64 bit Win that is independent of the navigator.userAgent. But that will have to wait until a future release.

[Adobe Reader] The Adobe Reader detection module has been rewritten and simplified. It is now also possible to detect the Adobe Reader plugin even when the ActiveX component of the plugin is disabled in the Internet Explorer addons menu. However, there is no guarantee that this new capability is future proofed.

[Adobe+ PDF Reader detection] An additional detector is now available on this website, called the Adobe+ PDF Reader detector. It is a combination of the Adobe Reader detector and the Firefox PDF Reader detector. It basically detects Adobe Reader, but it also warns you when the Adobe plugin is being overridden by the native Firefox PDF Reader. [Some people have expressed an interest in being able to detect this since Firefox 19 was released with a native PDF viewer.]

[Generic PDF Reader] The generic PDF Reader detector now has the ability to detect non-Adobe PDF Readers in Internet Explorer. Unfortunately, trying to detect certain PDF Readers in IE can cause a security popup to occur in the browser.



PluginDetect v0.8.0 (1/23/2013)

[QuickTime] Detection code for QuickTime on Internet Explorer has been rewritten. Detection speed has been improved slightly for IE. Also fixed a bug. The bug occured in that $.isMinVersion("QuickTime", minVersion) would sometimes incorrectly return -1 instead of -0.1 when QuickTime is installed and the plugin version < minVersion. It now correctly returns -0.1.

[Java] Version 5 of the getJavaInfo.jar applet has been released. This applet adds an isPlugin2() method, which will assist PluginDetect in determing whether Java is Plugin2 or not. Using this method should make Java Plugin2 detection a little more reliable. The applet is only used when/if Java starts up and runs during the course of plugin detection.

[Comment on Java 1,7,0,10+] This Java version introduces a higher default security setting. The result is that a security popup (generated by the Java JRE itself, not the browser) occurs when you try to run a Java applet in a web page. This is supposed to be a security enhancement, but this just makes Java less practical to use. And if the user still decides to give permission to run a Java applet on an unknown website, then their security is still compromised. Oracle is tacitly admitting that Java is completely insecure. Instead of actually getting Java to be safe and secure, they decide to add another layer of security popups (the first layer being the browser based Internet Explorer security popups). The reason why I bring this up is because the higher default security settings make Java detection less convenient under some circumstances.

[Comment on Java/Apple] Apple has decided to no longer officially support Java. So now, Apple will no longer be creating Java releases for Mac. Instead, Oracle will be creating Java releases for Mac. The Mac will no longer come preinstalled with Java. Users will have to manually install Java themselves from Oracle's website. The reason why Apple has dropped support is because Java is too insecure.

[Java] Oracle has made a number of changes to Java 7. As a result of this, one of the backup detection methods used by PluginDetect for Internet Explorer is now deprecated and will no longer be used. Instead, a generic detection method for IE has been added. This new method is already being used for QuickTime detection, and theoretically can be used as a generic detector for almost any IE plugin. This detection method is only used for Java detection in IE if the Deployment Toolkit plugin is not installed or not enabled. This detection method does not appear to trigger the Java based security popups in IE for Java 1,7,0,10+, and it does not require the Java/Javascript bridge in order to work. It has been tested to work on Internet Explorer 7+ and Java 1,2,2,7+.



PluginDetect v0.7.9.1 (11/23/2012)

[ ] This update only changes the getJavaInfo.jar for Java detection. The PluginDetect Library itself has not changed.

[AntiVirus, Java] My Avira AntiVirus suddenly started detecting the A.class file in my getJavaInfo.jar applet as malware. I submitted a false positive report to Avira TWICE. Each time they refused to acknowledge their mistake. So now, version 3 of getJavaInfo.jar is officially considered malware by Avira. [And yet, no malware detection occurs when my browser starts up Java and runs the applet. It appears the false positive detection only occurs when I ask my AntiVirus to directly scan the .jar or the .class]

As a result, I have decided to make a small change to the source code, and recompiled it to give us version 4 of getJavaInfo.jar. This new version no longer is detected as malware by Avira. The functionality has not changed at all, and I only had to change one byte. This demontrates how easy it is for AntiVirus scanners to be fooled by malware authors.

However, this update is not enough by itself. I now recommend that users download the getJavaInfo.jar applet and its source code, and then create your own CUSTOMIZED version of the applet. This customized getJavaInfo.jar applet along with the PluginDetect Library should be used on your own website to do Java detection. This customization should reduce the chances of any future false positive detections in AntiVirus scanners.


The instructions on how to customize are in the download.



PluginDetect v0.7.9 (10/17/2012)

[ ] PluginDetect will no longer officially support Internet Explorer 5.5. Support is now for Internet Explorer 6 and higher. Although, PluginDetect still appears to work for IE 5.5 anyway.

[ ] Website pages are now in HTML5.

[Internet Explorer] We added an option on the PluginDetect download page, which allows for an enhanced detection scheme for the Internet Explorer browser version. This enhanced version detection is no longer dependent on the browser's navigator.userAgent. The enhancement allows for 3 parameters to be available to the user: PluginDetect.verIE, PluginDetect.verIEfull, and PluginDetect.docModeIE. For details, see the instructions. We also added a page on Internet Explorer detection in the menu.

[Java] Small update.



PluginDetect v0.7.8 (6/7/2012)

[Java] Bugfix for Java on non-IE browsers. Oracle changed the format of the plugin numbers for Java 7+ in the navigator.plugins[x].description in Windows. I tried to compensate for this change in a previous PluginDetect version, but I misplaced a parenthesis, and that gave an incorrect detection result.


[Java] It turns out that the Deployment Toolkit can be instantiated with one of 2 different classids:
   "clsid:CAFEEFAC-DEC7-0000-0000-ABCDEFFEDCBA" and
   "clsid:CAFEEFAC-DEC7-0000-0001-ABCDEFFEDCBA"
JRE 1,6,0,10 - 1,6,0,19 uses the 1st classid.
JRE 1,6,0,20+ seems to support both classids.
JRE 1,7,0,4 (recently released) uses only the 2nd classid - which may be an Oracle bug, because beta versions of JRE 1,7,0,6 seem to support both classids.
Previously, PluginDetect only used the 1st classid. But now it will try either of these 2 classids to instantiate the Toolkit.


[Website] Added a menu



PluginDetect v0.7.7 (4/11/2012)

[Licensing] I've had a few requests about licensing terms, so I figured it was time to just get that stuff out of the way. I'm releasing PluginDetect under the MIT license. It's a simple license, and it's easy enough (for me) to understand.

[ ] Added a "Save" button to the Script Generator to make it easier to save the script.

[ ] The detection code for each plugin is now inside a new PluginDetect.Plugins{} object. This allows for greater modularity of PluginDetect, and prevents namespace pollution from any additional plugins that are ever added. So instead of PluginDetect.java we have PluginDetect.Plugins.java, etc...

[ ] Changed the way we insert HTML tags into web page for better reliability.

[Safari] Added PluginDetect.verSafari to give the Safari browser version #. Browser version is only available for Safari 3+.

[Java] The Java detection module has been reorganized so that it would be easier to maintain.

[Java] Added new numbers that can be used in the verifyTagsArray. The new numbers are 2.2, 2.5, and 2.8. See docs on Java page for further details. These new numbers give us more flexibility for Java detection.

[Java] The default value for the verifyTags array has been changed. It PREVIOUSLY was [2,2,2], which means that both <object> and <applet> tags would be used to run Java if the non-applet detection methods could not find any Java.

The default for verifyTagsArray for all modern browsers / platforms is now [1,0,1], meaning we only use <object> tags to run Java applets. The default for verifyTagsArray for some older Desktop browsers is [1,1,1], meaning that either the <object> tag or the <applet> tag is used to run Java, whichever works first.

There are 2 reasons for this change:
1) The <applet> tag is deprecated, so we no longer encourage it's use in modern browsers. The <object> tag is the way to go. Java should be treated like any other plugin, and does not deserve it's own special <applet> tag.
2) For Safari, Chrome, older versions of Firefox & Opera, when you try to instantiate an <applet> tag when Java is not installed, you may get a popup asking to download Java. The <object> tag does not usually give a popup.

The Java detection code was also updated to more precisely follow the rules as specified by the verifyTagsArray. The user can still override the default value for verifyTags by setting it to something else. But it's not really recommended.

[Java] For Internet Explorer, we now use the HTML5 compatible <object> tag when instantiating a Java applet. This HTML5 <object> tag works for IE 6+, JRE 1,6,0,12+. For JRE < 1,6,0,12, this HTML5 <object> tag will not detect Java. However, I believe it is better to be forwards compatible with an HTML5 <object> tag than backwards compatible with a non-standards compliant <object> tag.

The HTML5 <object> tag we are referring to here does NOT use ActiveX. For Internet Explorer, PluginDetect also uses an <object> tag with ActiveX, and an <applet> tag to instantiate Java.


[Java] PluginDetect will not try to correct the mistakes/stupidity of other people. If someone installs a version of Java that is not compatible with their browser (like Java 1,7,0,3 into Firefox 2/Windows) then PluginDetect may or may not try to detect this scenario. We must usually assume that the user has installed a compatible Java into their browser, or no Java at all. We assume that the user will eventually notice whether Java was incorrectly installed or is not compatible with their browser.
We make this assumption because otherwise PluginDetect would be too hard to maintain.


[Java, Opera] Opera 10.5 introduced support for Java Plugin2. So, lower versions of Opera will not run Plugin2. We check for this now. http://my.opera.com/sitepatching/blog/2010/02/25/new-java-support-and-object-parsing


[Java] It is no longer a given that Java comes preinstalled on Macintosh. Therefore, we no longer assume that Java is always installed on that platform. We got rid of any code from PluginDetect that made this assumption. That code only applied to very old Safari/Mac systems anyway.

[PDF Reader] The more recent versions of the PDF.js addon can be detected by our Generic PDF Reader detecter, because PDF.js now works with <object> tags.

[Comment] The problem with plugin detection is that there are NO REAL STANDARDS. There are some generally accepted conventions, but no standards. If a developer decides to break these conventions, then there is nothing to prevent them from doing so.
For example, Apple's Safari has a Java mimetype in the navigator.mimeTypes array, even when Java is not installed. Apple has nothing in the mimetypes array for application/pdf in the iPad, even though their browser displays pdfs in the <object> tag with the same mimetype.

[Comment] Java 1,7,0,0 to 1,7,0,3 (by Oracle) does not seem to work very well. Lots of bugs. I do not recommend it's use until they fix it. Best to stick with JRE 1,6,0,XX for now.



PluginDetect v0.7.6 (2/3/2012)

[Website] Had to change the structure of the website to make it easier to maintain. Incoming links to old pages are redirected.

[Hotlinking] I am no longer allowing hotlinking to the scripts on this website. You are going to have to upload the scripts to YOUR OWN SERVER. PluginDetect is free, my bandwidth is not.

[Comment] Some folks who enjoy spreading malware have been using PluginDetect to assist them. I don't know whether I should be flattered or insulted. They use PluginDetect to find a vulnerable plugin (an outdated Adobe Reader or Java, or whatever), and then proceed to deliver the malware to screw up your computer. PluginDetect was never intended for that. I therefore wonder if an antivirus scanner will someday see PluginDetect itself as malware. So far, this does not seem to be the case. [PluginDetect does not contain any trojans/viruses/malware.]
  It is because of malware that Chrome does not allow certain plugins to run, by default, if they are not completely up to date. You get a popup instead. Obviously we don't want any popups during plugin detection. This places a limit on the information obtained by plugin detection.

[WMP] The Chrome browser gave a popup when trying to detect the Windows Media Player plugin version. This is because we tried to instantiate the plugin. Hence, PluginDetect now prevents Chrome from running the plugin when doing detection. So, we can no longer determine the WMP plugin version for Chrome. We can only see if the plugin is installed or not.

[Flash] Increased the precision of the detected plugin version for non-IE browsers. Flash version numbers normally consist of major.minor.release.build. Previously, PluginDetect would only show major.minor.release.0 for non-IE browsers by looking at the navigator array [Except for Firefox 3.6+ on Windows, which reveals the build # in the navigator array.] Now, however, we use the instantiated Flash <object> tag, and query this object ON THE FLY to get the build number. If the <object> tag does not fully load on the fly, then we fall back on the numbers found in the navigator array. The Chrome browser will not give any security popups when instantiating the Flash object, because Flash is built in to the browser. So Flash detection on Chrome is not a problem.

[ ] We added a new status # to the PluginDetect.isMinVersion(pluginName, minVersion) method. When it returns -0.1, then the plugin is "installed and enabled, but version is < minVersion".

[ ] We changed the meaning of PluginDetect.isMinVersion() == -1 slightly. When the method returns -1, it means that the plugin is "not installed or not enabled". It PREVIOUSLY meant "not installed or not enabled or version < minVersion". We no longer need the "version < minVersion" part because of the new -0.1 return value for PluginDetect.isMinVersion.

[WMP] Windows Media Player detection now allows input mimetype to be specified. This way you can check if the plugin is associated with a particular mimetype. The mimetype is specified as an input argument to PluginDetect.isMinVersion.

[ ] After the web page has fully loaded and all detection has been completed, PluginDetect will now remove the <div id="plugindetect"></div> from the DOM. It is removed regardless of whether PluginDetect itself added this <div> to the page, or the user added this <div> to the page. We made this change so that PluginDetect would be less obtrusive.
Note: The <div id="plugindetect"></div> is used when PluginDetect needs to insert any <object>/<applet> tags into the web page to assist in plugin detection.

[Java] We changed the brute force Java ActiveX search in IE from [1,6,1,30] to [1,6,1,40]. This brute force search only occurs if the Deployment Toolkit is disabled. We made this change because Oracle recently came out with JRE 1,6,0,30 and we do not know how high they are going to go. But since they are beta testing 1,7,0,0 right now, I suspect that they will not go much higher for the JRE 6 series.

[Java] Fixed a small bug in the way the input argument jarfile string is handled. Created a PluginDetect object to handle the input jarfile string. The claim has always been that you only needed to input the jarfile in the first Java related PluginDetect command, and then PluginDetect would remember the value of the jarfile string for all subsequent commands. It turns out that in certain very rare circumstances, that would not be strictly true. This small issue has now been resolved.

[Java] Instantiated Java <object> tag for non-IE browsers is now HTML5 compatible. HTML5 does not allow "classid" or "archive" to be used as attributes of <object> tag, so we had to drop those and use an alternative. I decided to do this when a Chrome bug was reported a while back. Apparently, Java applets using an <object> with a classid parameter did not run in that browser. They probably fixed the browser bug since then.

[Generic PDF Reader] In order to verify the [path/]name of DummyPDF, you now have to select that as an option in the PluginDetect Script Generator web page. Made some changes to the PDF code to make it cleaner.

[Verify] Updated the verify jarfile code and the verify DummyPDF code.

[ ] Status messages, verify Jarfile messages, and verify DummyPDF messages are now always in a <div> that appears in window.top.document.body. We do this in case PluginDetect is inside a frame, so that the messages always appear in the topmost window.

[AdobeReader, RealPlayer, WMP] Small changes in the way the mimetype input argument is handled. The input string is now case sensitive, because it is theoretically possible for a mimetype to have lowercase and/or uppercase letters. Usually, however, most mimetypes are only lowercase.



PluginDetect v0.7.5 (3/22/11)

[QuickTime] Plugin detection for recent versions of QuickTime has been a bit slow in Internet Explorer. Therefore, we improved the speed of isMinVersion( ) for QuickTime in Internet Explorer. The speed of getVersion( ) remains the same. If QuickTime detection speed is an issue for your web page, then use isMinVersion( ) instead of getVersion( ). This speed optimization was only done for the QuickTime plugin.

[RealPlayer] Added RealPlayer plugin detection.

[Java] Got a bug report for Java detection in Firefox 3.6.12 on Mac OS 10.6.5. The browser hangs when Java is disabled and you are using PluginDetect. It appears that the browser's Javascript interpreter crashes. The crash occurs when we use winJava.lang.System.getProperty('java.version'). This is an old Gecko-based bug that was supposedly solved by Mozilla a while back. Somehow it seems to have come back. Hence, PluginDetect now uses a workaround for this problem for all Gecko browsers. At some point, we may just entirely avoid using lang.System.getProperty('java.version') for all browsers, since it is officially deprecated by Sun.

[Java] Chrome browser gives a popup for the Deployment Toolkit. So we avoid using the DTK in Chrome. It appears that Chrome 10+ gives a popup in the browser window whenever you try to run an outdated plugin. This is a problem for certain plugins, which require instantiation in order to do detection.

[PDF Reader] A few small changes made. Also, we updated the DummyPDF file used for detection. It is now 921 bytes in size.



PluginDetect v0.7.4 (9/27/10)

[ ] PluginDetect now will show status/error messages at the top of the web page when that option is selected in the script generator page. Showing status messages is ONLY for testing/debugging purposes.

[ ] PluginDetect will no longer support Internet Explorer 5. Support is now for Internet Explorer 5.5 and higher.

[Java] PluginDetect now will verify whether the path/name of the jarfile in your Java detection code is correct or not. The "Verify jarfile" option is available in the script generator page. This option is ONLY for testing/debugging purposes.

[Java] The Java applet has been updated to version 3.0. This applet is named getJavaInfo.jar.I decided against putting the version number in the applet name, so that the documentation would be easier to maintain whenever I come out with newer versions of the applet. This Java applet has not been compressed by any 3rd party applications, unlike the previous versions.

[PDF Reader] We added a Generic PDF Reader detector to PluginDetect. This is designed to handle a wider variety of PDF Readers in addition to the Adobe PDF Reader. It can also handle browsers that have built-in PDF capability, like Safari/iPad and Safari/Mac.



PluginDetect v0.7.3 (6/5/10)

[Browser Detection] A few browser detection variables used by PluginDetect have been changed or added:
          PluginDetect.IEver is now PluginDetect.verIE
          PluginDetect.GeckoRV is now PluginDetect.verGecko
          Opera version detection has been added as PluginDetect.verOpera

[Adobe Reader] Detection for this plugin has been rewritten and enhanced to take advantage of Firefox 3.6+. Firefox 3.6+ allows a new method of detection to get the plugin version, and so we do a consistency check to make sure the result makes sense. Also, detection slightly enhanced for IE as well.

[Flash] The 4th digit for the Flash plugin version is now available for Firefox 3.6+ and IE. Other browsers will have '0' for the 4th digit because that info is not available.

[Shockwave] The 4th digit for the Shockwave plugin version is now available for Firefox 3.6+ and IE. Other browsers will have '0' for the 4th digit because that info is not available.

[Silverlight] PluginDetect will no longer try to instantiate Silverlight in any non-IE browsers when doing detection. The reason for this is that older versions of Silverlight may cause a crash in some browsers. To avoid this, we simply do a passive detection in the navigator array. It is thus the users responsibility when embedding a silverlight app in a web page to make sure that some minimum version of the plugin is present. You may use PluginDetect.isMinVersion() to make sure that some mimumum version is installed.

[WindowsMediaPlayer] Had to exclude Opera version < 10 from instantiating the Firefox WMP plugin to get the precise plugin version. The reason is that in some rare cases Opera 9.00 /Windows would crash when instantiating the plugin (using "application/x-ms-wmp" mimetype, and even then would only crash sometimes). Anyway, Opera < 10 cannot query the plugin for the version anyway.

[VLC, WMP] We filter out the Totem media player under Linux, because it mimics VLC and Windows Media player.

[QuickTime] QuickTime can now be detected on the iPad. QuickTime version info is not available on the iPad.

[ ] Despite the fact that the PluginDetect script is already minified by Yui, some people may still want to additionally process the script thru their own Javascript minifier. The problem here is that not all minifiers behave the same.
   The PluginDetect script contains a conditional compilation, which is used to identify Internet Explorer. At least some Javascript minifiers do not recognize conditional compilations, and simply treat them as a comment to be removed from the script (Yui does not have this problem).
   This issue now appears to be fixed. PluginDetect should now work, regardless of whether the minifier used is able to recognize conditional compilations.



PluginDetect v0.7.2 (4/19/10)

[Java] PluginDetect.getInfo('Java').DeploymentToolkitPlugin no longer returns true/false. It now returns the instantiated Deployment Toolkit plugin object, assuming the plugin is installed and enabled. It returns null when the plugin is not installed or not enabled. This change allows you to interact with the Deployment Toolkit plugin if you feel it necessary.

[Adobe Reader] Added detection for Adobe PDF Reader.



PluginDetect v0.7.1 (3/22/10)

[Java] added new feature - PluginDetect.getInfo('Java').isPlugin2 to detect if the Java plugin is the Next-Generation of Java plugin.

[Java] added new feature - PluginDetect.getInfo('Java').PLUGIN which returns an instantiated Java applet.

[Java] Code for Liveconnect query of Java without using applets is more robust. The main problem has been the Gecko Javascript interpreter crash that occurs when Java not installed and you try to do the query. We narrowed the bug down specifically to the Gecko rv:1.8 branch. All other branches are free of this bug. We simply prevent that branch from performing a Liveconnect query without the Java plugin.

[Java] We added 2 more Java mimetypes that PluginDetect can check for.

[Java] Bugfix. Setting "display" property to "inline" using javascript, for object/applet tag will prevent Gecko rv<1.5 from firing window.onload event. So, we avoid this for outdated Gecko. Strange, since default style for those tags is inline anyway.

[Java] Fixed a small bug from the previous release. Non-IE browsers would show NOTF detection when verifyTags = [3,3,3], even if the detection was actually OTF.

[Java] An attempt was made to make Safari/Windows compatible with Java Deployment Toolkit plugin. However, it turns out that under certain circumstances Safari 3&4 will crash. For this reason, PluginDetect will not instantiate the Deployment Toolkit for Safari/Windows.

[Java] NOTF detection now uses setTimeout() instead of setInterval().

[Java] We no longer try to detect multiple JREs in the mimetypes array. We only try to detect the highest version in the mimetypes array. The mimetypes array is not reliable for detecting multiple JREs anyway. It never worked for Mac/Linux anyway, and was not reliable for Windows. And for Windows, the Deployment Toolkit finds multiple JRE's anyway.

[Java] Bug fix for Chrome & Firefox 3.6+, which both require the new Java Plugin. Those browsers are incompatible with the old Java plugin. For Windows, Firefox 3.6 seems to need JRE 1,6,0,12 or higher. The same goes for Chrome. The bug is if the Deployment Toolkit is installed and a lower Java version is present, then PluginDetect would say that Java was installed and enabled, which clearly is not the case.

[Java] When JRE < 1,6,0,10 is installed in Firefox 3.6, then PluginDetect should now show the installed version and say that Java is installed but not enabled, as opposed to just saying that Java is not installed. This does not work for Chrome, since Chrome does not reveal enough info for JRE < 1,6,0,10.

[QuickTime] There was one case where IE 7 WinXP system that never had QuickTime installed, would cause a security popup. Removed the offending code that could cause that.

[QuickTime] PluginDetect.beforeInstantiate() method now integrated with QuickTime plugin as well. The reason for doing this is that PluginDetect will instantiate QuickTime for Internet Explorer 7+ in order to do detection.



PluginDetect v0.7.0 (2/3/10)

[Java] getJavaInfo.jar, getJavaInfo2.jar and Java examples are now all contained within a single zip file called Java_Apps.zip.

[Java] PluginDetect now compatible with the new mimetype for Java Deployment Toolkit.

[ ] The getVersion() output is comma delimited by default, but the user now is able to select another delimiter if he wishes. See instructions page.

[Silverlight] If Silverlight is installed but not enabled then isMinVersion() now returns -0.2. BTW, Opera 10.10 seems to have Silverlight enabled and running properly, whereas Opera 9 has Silverlight installed but not enabled.

[Java/Opera] Opera 10.10 seems to have a serious bug. When Java is not installed or not enabled, and we try to instantiate an applet tag using innerHTML, and then try to query that applet, the browser will hang. PluginDetect tries to work around this bug.

[ ] PluginDetect.beforeInstantiate(pluginName, F) method has been added. When plugin instantiation is attempted (ie. plugin may start) for the purpose of plugin detection, event handler F will be executed. Function F will run BEFORE the plugin starts. The purpose for this method is that certain plugins (ie. Java) can be very slow to start up, and so executing function F beforehand can serve as a warning that a startup delay may occur. Of course, having function F run is no guarantee that the plugin is even present. It merely tells you that an ATTEMPT will be made to start up that plugin.

[ ] Event handler F can now be specified with up to 3 input arguments. Simply substitute the event handler F with an array [F, arg1, arg2, arg3]. The event handler F will be executed with the following input arguments: F(PluginDetect, arg1, arg2, arg3). Note that the event handler F automatically gets the PluginDetect object as an input. This applies to PluginDetect.beforeInstantiate(), PluginDetect.onWindowLoaded(), and PluginDetect.onDetectionDone().

For example, PluginDetect.onWindowLoaded(F) will execute F(PluginDetect) when the window loads and PluginDetect.onWindowLoaded([F, arg1, arg2]) will execute F(PluginDetect, arg1, arg2) when the window loads.

[Java, DevalVR, WindowsMediaPlayer, Silverlight] The <div id="plugindetect"></div> is now less intrusive in the web page layout. You are allowed to use the css property position:absolute. The user can also add the css position to the div such as left (or right) and top (or bottom). For example,

    <div id="plugindetect" style="position:absolute; left:10px; top:20px;"></div>.

The position:absolute style prevents the div from interfering with the positioning and layout of the rest of your website. See Instructions page for further details.

[Java] Bugfix for detecting broken Javascript/Java bridge in IE 8

[Java, DevalVR, WindowsMediaPlayer, Silverlight] Bugfix. Instantiated plugins on the page are inside <div><span>plugin</span></div>, and thus the plugin objects are now given style display:inline

[Java] The java applet has been updated to version 2.0 and is named getJavaInfo2.jar. (The old java applet, version 1.0, is named getJavaInfo.jar) The applet was updated so PluginDetect can add some new Java features in the future. The new applet is backwards compatible with older versions of PluginDetect. You may continue to use the old getJavaInfo.jar applet with PluginDetect if you wish, it just won't be quite as versatile.

[Java] When the java applet starts up, some browsers show the "Applet Started" message in the status bar. PluginDetect attempts to replace this message with a single whitespace. This works in some cases, but not all. Seems to be a feature of the browsers/JREs. This new feature is only available with the new getJavaInfo2.jar applet.

[Java] When Java applets are inserted into the page, we now use the codebase attribute to show that the jarfile is in another folder. This is the STANDARD way of doing things when the jar/class are in a different directory. Up until now, we were putting the path of the jarfile into the archive attribute. IE seems to require the codebase attribute to be a <param name="..." value="...">

[Script Generator] When you deselect a method on the Script Generator page, that method is now completely eliminated from the output script. This is to make the script as small as possible. Previously, any deselected method would still exist in the output script as an empty function, which is a waste. Also, when you reload the Script generator page, it will now reset properly.



PluginDetect v0.6.3 (6/17/09)

[Java] Firefox 3.0.11 crashes in certain circumstances when using PluginDetect. The browser also crashes with deployJava.js. The reason for this has to do with a bug in Firefox that occurs when the Java Deployment Toolkit plugin is queried. A workaround has been found for PluginDetect to prevent the browser from hanging. In the meantime, Mozilla needs to fix the browser.

[Java] Small modification has been made, so that it will be possible for users to verify that they correctly specified the jarfile name and path in their plugin detection.



PluginDetect v0.6.2 (5/25/09)

[Java, DevalVR, WindowsMediaPlayer, Silverlight] PluginDetect often needs to insert a plugin object into your webpage in order to do plugin detection. For example, to detect Java, PluginDetect may have to insert an <applet> tag into the page, and then query that applet to get the Java version.
By default, all plugin instantiations are inserted at the very top of the web page. The plugin instantiations are several pixels high. When window.onload occurs, all the plugin objects are removed from the page. The problem here is that putting these few plugin objects at the top of the page may, in some cases, affect the layout of your page. As a result, PluginDetect now allows you to specify where in the page these plugin objects should be inserted. Place a div in the format of <div id="plugindetect"></div> anywhere in the <body> of your webpage, but BEFORE the code that does your Java detection. All instantiated plugins will go into this div. If you do not specify this div, then PluginDetect will simply use the default location at the beginning of the page.

[Bugfix Java] When verifyTagsArray = [3,3,3] and you load JavaDetect.htm in IE8 with JRE 1,6,0,2 and then you try to reload the page, the reload is VERY slow when document not focused, or the browser may even hang.
Solution: We need to force focus on the applets when querying Java applets when document is blurred. For example, if you run a webpage with Java detection, but the mouse is outside the window, then the document may not have focus. In that case, when you query the applet the browser (IE) will just hang until you move the mouse into the document. In cases when document.hasFocus()==false, we force the browser to focus on the applets during the Java applet query.

[Bugfix Java] Google Chrome browser would give a popup if no Java present, or JRE < 1,6,0,10

[Bugfix Java] Until now, just about every browser would throw an error when applet.getVersion() query is unable to give a result. This was expected and was handled with try{}catch{}. But it seems that Chrome will not throw an error. So we needed to make a minor adjustment in our Java applet query routine.
(BTW, Java applet querying in Chrome 2/JRE 1.6.0.10 appears to be very flaky. For example, applet.parentNode will not return the parentNode. Instead it returns [Java Package "parentNode"]. This is a browser bug. The applet.getVersion() query seems somewhat broken also, even though it works for all other browsers. Java detect for Chrome will not work completely until this Java/browser bug is fixed.)

[Bugfix Java] Fixed ability to detect broken Java/Javascript bridge in Opera 8+.

[] Starting to use a few suggestions from JSLint.



PluginDetect v0.6.1 (4/6/2009)

[QuickTime, Bugfix] There was a small bug in QuickTime detection in IE. The reason
for this had to do with a bug in QT 7.5.5 codebase. Apple fixed the problem in QT 7.6.

[All plugins, New Feature] For onDetectionDone(pluginName, f) and onWindowLoaded(f)
the event handler f now automatically receives the PluginDetect object as an input argument.

[Java] Updated OTF_detection.js and NOTF_OTF_detection.js.



PluginDetect v0.6.0 (4/2/2009)

[] We now use the Yui compressor to shrink the script. It gives a slightly better compression.

[All plugins, New Feature] PluginDetect.onJavaDetectionDone(f, jarfile) has been converted to PluginDetect.onDetectionDone(pluginName, f, jarfile). The PluginDetect.onDetectionDone() method can be used for all plugins. However, it is really only neccessary for NOTF Java detection.

[Java, New Feature] PluginDetect.onDetectionDone(), isMinVersion(), and getVersion() methods now have another optional input argument for Java - verifyTagsArray. This argument comes right after the jarfile input argument. When doing plugin detection, the verifyTagsArray argument controls when a Java applet is instantiated, to verify that Java is actually capable of running in the browser.

[Java, New Feature] Added new output PluginDetect.getInfo('Java'). This object has the properties: vendor (string), DeployTK_versions (array of strings, list of installed Java versions as detected by the Deployment Toolkit plugin), MimeType_versions (array of strings, list of installed Java versions as found in the navigator.mimetype array), All_versions (array of strings, list of all installed Java versions from all possible sources), name (string from navigator.plugins[x].name), description (string from navigator.plugins[x].description), DeploymentToolkitPlugin(boolean, tells if Deployment Toolkit is installed/enabled).

[Java, New Feature] Whenever possible, PluginDetect will reveal when Java is installed but not enabled. Note - the Deployment Toolkit browser plugin does not distinguish between Java enabled and Java disabled in a browser. So, if you disable Java in Firefox, the Deployment Toolkit still detects Java. We had to adjust PluginDetect to take this into account for all non-IE browsers.

[Bugfix Java] Fixed a small bug in the sample script OTF_detection.js. Updated OTF_detection.js and NOTF_OTF_detection.js.

[Bugfix Java] IcedTea Java has a bug - often gives navigator.javaEnabled()==false even though Java is not disabled. This occurs when you try to get the Java version via the Javascript to Java bridge (which is broken in IcedTea Java 1,7,0,0 in FF 2 under Ubuntu), which then causes navigator.javaEnabled() to become false. This bug has been dealt with.

[Bugfix Java] Trying to instantiate the Deployment Toolkit on older Gecko browsers caused a popup due to plugin crash. Also, the Toolkit object is only deleted after window.onload, in case we need to use the object at some point.

[Java] We switched the order of Java detection attempts for non-IE browsers. We now check for "application/x-java-applet;jpi-version=..." mimetypes before checking the navigator.plugins array. We now look for all unique Java versions in the mimetype array. This allows us to detect multiple JREs for non-IE browsers in many cases.

[Bugfix Java] Small bugfix in searchJavaAXO(). We added a check for WebStart.

[Java] If the DeploymentToolkit plugin is not present or not enabled, then PluginDetect will attempt to detect multiple JRE's using other methods: - For IE < 7, it will detect multiple JREs from 1.5.0.7+. For single JRE detection it will detect from 1,3,1,0+. - For IE 7+, it will detect multiple JREs 1.6.0.2+. For single JRE detection it will detect from 1,3,1,0+. - For non-IE browsers, multiple JRE detection is limited by what the browsers are willing to reveal. Firefox 3, for example, will only reveal the highest installed Java version.

[Bugfix] - There is a bug in IE as documented here: http://blogs.msdn.com/ie/archive/2008/04/23/what-happened-to-operation-aborted.aspx. If you put a PluginDetect command in a <script> element in the <body>, and if that <script> element is not in the top level of the DOM heirarchy in the <body>, then IE could give you an error message. I found a way around this to avoid the IE error. You should now be able to put PluginDetect commands in any level of the heirarchy in the <body>.



PluginDetect v0.5.0 (11/11/2008)

[QuickTime] Some media players in Linux try to fool plugin detectors into thinking that QuickTime is installed. We added some code to make sure that does not happen here. We want to be able to distinguish between a genuine QuickTime plugin and a 3rd party plugin that just pretends to be QuickTime. Why? Because most 3rd party apps do not play QuickTime VR.

[QuickTime] Bugfix. PluginDetect was not able to detect QuickTime 4 under IE 7+. Fixed this, although it is extremely unlikely to have QT 4 and IE 7+ on the same system.

[New Feature] PluginDetect.hasMimeType(arg) is a new routine the user can access to see if a particular mimetype is present and enabled. The input "arg" can be a string (mimetype) or an array of strings. If the mimetype is not present, then it returns null, otherwise it returns the navigator.mimeTypes(arg) object. Why add this feature? Say you wanted to play a QuickTime .mov video, but that the video has the capability to be played in any old media player that handles this mimetype. In this case, you don't really need to check for the genuine QuickTime. You only need to check for the mimetype.

[Java] We added a new output value of -0.5 or +0.5 to PluginDetect.isMinVersion('Java', [...], jarfile). When PluginDetect.isMinVersion('Java', [...], jarfile) == -0.5 then this means that Java may or may not be present, but the specific Java version cannot be detected until you wait for the Java JRE to load.
  When PluginDetect.isMinVersion('Java', [...], jarfile) == +0.5 then this means that Java is present, but we must wait for the JRE to run to get the specific Java version. Hence, we use PluginDetect.onJavaDetectionDone(f, jarfile) to execute function f. Function f will be able to access the Java detection results.

[Java, New Feature] PluginDetect.onJavaDetectionDone(f, jarfile) is a new method that executes the function f after Java detection has been fully completed. This could occur before or after the window.onload event has occured. The results of Java detection will be available to the function f. The reason for this new feature is because some browsers need to wait until window.onload before the Java version is available (ie. Java detection not done on the fly) In the majority of cases, Java detection is done on the fly (OTF).

[New Feature] PluginDetect.onWindowLoaded(f) is a new method that executes the function f after window.onload has fired. The results of the Java detection will be available to the function f.

[Java] Java detection in the Konqueror browser now is possible. Java detection of the outdated Microsoft JVM is now also possible. These are made possible due to the new -0.5,+0.5 output value of PluginDetect.isMinVersion('Java', ...)

[Java] If the external Java applet is used to detect the Java version, then it will now only be deleted from the web page after the window has fully loaded, as opposed to deleting before the window has loaded. The reason for this is that the window.onload event may not fire in Konqueror if you delete an applet before the window loads. [Seems to be a browser bug].

[Java] If you use PluginDetect.getVersion('Java') and Java not installed and then you use PluginDetect.getVersion('Java', jarFile) then PluginDetect will perform the actual detection twice, because the second time the jarFile is specified which might lead to Java being detected as installed.

[Java bugfix] When Java is not installed, Safari on Windows would incorrectly say that java was installed. This was for OTF detection when no external jar file is being used. We fixed this. However, Safari on MacOSX by default will always show that Java is installed.



PluginDetect v0.4.9  (7/02/2008)

[DevalVR] Changed the technique used to detect the version # for the DevalVR plugin in Internet Explorer. Instead of using the codebase technique, we simply instantiate the plugin with an <object> tag, and then query the plugin to get the version.

[Silverlight] Bugfix needed so that Silverlight could be properly detected in Firefox 3.

[Java] Redundant code PluginDetect.java.isMinVersion() method has been removed since it is no longer needed. This does not affect PluginDetect.isMinVersion('Java',...) in any meaningful way. But it does make the java detection code a little smaller.

[QuickTime] Redundant code PluginDetect.quicktime.isMinVersion() has been removed. This does not affect PluginDetect.isMinVersion('QuickTime',...) in any meaningful way. Also, we clip the version numbers for QuickTime detection to 3 digits, so that the 4th digit is ignored (Internet Explorer can reveal the 4th digit, but Firefox does not, so we clip to 3 digits so that results are consistent across all browsers).

[QuickTime] Bugfix. It appears that Apple has changed the way the codebase versioning works for QuickTime 7.5.0. This caused PluginDetect to give the wrong version # output for QuickTime. For QuickTime 7.5.0 the codebase is now "#version=7,50,61,0" instead of '#version=7,5,0,61'. The "QuickTimeCheckObject.QuickTimeCheck.1" object still gives the correct 7.5.0 return value, however it is still not a pre-approved control for IE 7+.



PluginDetect v0.4.8  (6/02/2008)

formatNum() method has been changed, due to adding VLC plugin detection. That plugin has letters in it's version numbers, so I had to change the way we get rid of leading zeros in a version number.

Renamed some functions so they make more sense.

[Java] Added the ability to use an <applet> tag for external java applet (getJavaInfo.jar) for java detection. This was needed because Safari 1 & Safari 2 on Macintosh do not handle the <object> tag very well to instantiate a java applet. An external applet will first be instantiated with an <object> tag, since that is standards compliant. We only use <applet> tag after the <object> tag fails to give any result. The <applet> tag is deprecated, but that won't matter since older browsers won't care.

[Java] Bugfix. Because IcedTea Java under Linux has a bug ( often gives wrong value for navigator.javaEnabled() ) we will assume that javaEnabled() = true always. We therefore just check for the java mimetype, check for linux OS, and IcedTea in navigator.plugins array.
  To blindly rely on the buggy value of navigator.javaEnabled() for IcedTea would cause PluginDetect to believe that java was disabled. The disadvantage here is that if you disable java in the browser prefs, then we falsely say that java is enabled when it really is not.
  Another bug with IcedTea is that I have no luck with LiveConnect.

[Java] Bugfix. There was a small problem with Avira AntiVirus and Java detection on local hard drive. When you are on your local hard drive, and you right-click on JavaDetect.htm file and open-with IE 7, then IE 7 (WinXP SP2) may hang for JRE 1,5,0,01 (and other JRE's as well).
This occured when Deployment Toolkit is not installed, and we then try to use queryExternalApplet() or codebaseSearch(). To fix, we run JavaFix() AFTER searchAXOJavaPlugin() but before queryExternalApplet() or codebaseSearch().
   This bug does not occur if I open another web page locally, and then click on a link to go to JavaDetect.htm. This bug does not occur when I turn off Avira AntiVirus. This bug does not occur when JavaDetect.htm is on a web server. This bug does not occur for IE 8 beta1.



PluginDetect v0.4.7 (5/14/2008)

Added support for the VLC Player.



PluginDetect v0.4.6 (5/13/2008)

[Java] When accessing the 'object' or 'readyState' properties of an applet, it is possible to get an "Access is denied" popup error in Internet Explorer. Therefore we put all obj.object and obj.readyState commands inside a try-catch statement to avoid this. The reason for this is if your Security settings are set so that "Scripting of Java applets" is disabled in Internet Explorer, then you could get an "Access is denied" popup error for the method java.queryExternalApplet(). So, I now put ALL obj.object and obj.readyState into a try-catch just to be on the safe side.

[Java] Any obj.classid = ... statement we put inside a try-catch statement.
The reason is that one user claims to get an "Access is denied" error on obj.classid=...

[Java] Bugfix. PluginDetect.java.queryExternalApplet() could possibly have run more than once. I added code so that it can only run once.

[Java] Bugfix. For Java, digits [...] array should only have entries 2^N where N>=0 integer. changed from digits=[1,9,32,32] to digits=[2, 8, 8, 32]



PluginDetect v0.4.5 (5/9/2008)

[Java] We made the Java detection attempt # 1 for non-Internet Explorer browsers more generic. We now look at both plugin.description and plugin.name, instead of just looking at plugin.description. If a Java version number is present in both, then we take the one with the higher number. In Ubuntu, for example, I often see a version number in both. For Blackdown Java in one I see 1.4.2 and the other I see 1.4.2-03, so I wanted to pick 1.4.2-03.

[Java] Iced-Tea Java in Ubuntu now is detected. Detects JRE 1.7 for Ubuntu 7.10 in Firefox.

[Java] Bugfix. That longstanding bug where I reboot PC, then load Java Detection web page locally into IE 7/8 without IE having connected to the Internet first, and then IE hangs/crashes, has been solved. (Bug possibly related to codebase detection method).
  Bug goes away when I updated ZoneAlarm Pro 5.5 to ZoneAlarm Free 7.0. The bug never happened when I uninstalled ZA, and was using the WindowsXP firewall. The bug also does not happen when I unplug the router (ie no internet connection). The bug also never happened when loading the Java Detection web page in the Internet zone.

[Java] DebugBar 5.0.2 for Internet Explorer caused a crash locally when I use PluginDetect for Java, with JRE 1,4,1,0 (or lower) and IE 7 (or 8). Actually, just using new ActiveXObject("...") and then instantiating <object classid="8AD9..."></object> causes the crash. So, we may want to disable the DebugBar sometimes.

[Java, QuickTime] Got rid of VBScript, since it is not really needed. Javascript alone is more than sufficient.

[Java] We added the ability to query an externally loaded applet (getJavaInfo.jar). This applet can be instantiated via an <object> tag (but without any classid). This may be useful in 2 ways:

A) For Internet Explorer 7+, if the classid 8AD9.... is no longer approved, then using that classid to detect the Java version could cause a popup. The applet would help avoid the security popup in that case. Normally the classid has been preapproved by Microsoft. However, I have noticed that the newer versions of Sun Java (1.6.0.02+), when you uninstall them, they remove the classid from the preApproved registry key (bad idea). If you then install a lower JRE that does not put the classid back into the registry key, then classid 8AD9... used for plugin detection would give a popup. The applet instantiated with an <object> tag but no classid would sidestep this potential problem.

B) For Safari/Mac, hopefully it is now possible to get the Java version. The drawback here is that we do not wait for window.onload before querying the applet. We simply query the applet immediately. Newer versions of Java do not appear to need window.onload, but older versions do. Still need to test this on Macintosh.


[Java] For the Deployment Toolkit, we store all the detected versions in PluginDetect.java.allVersions = [...] array

[Java] Bug fix. In the script generator for Java, when they choose isMinVersion() and deselect getVersion() the routine did not work correctly. The BOUNDARY() was in the wrong place in the $.codebaseSearch() method.



PluginDetect v0.4.0 (4/11/2008)

[Java] We took some steps to increase the speed of Java detection. We try to use the faster methods first, then the slower methods if the fast ones fail.

[Java] We added the ability to instantiate the Deployment Toolkit Object, and query that object to get the Sun Java version. The Deployment Toolkit is supposed to be the "officially" supported way of doing Java plugin detection in the future, and is supposed to be very fast in doing detection. It is part of Java 1,6,0,10. This version of Java has not been officially released yet. However, anyone that has never installed 1,6,0,10 or greater will of course not have an easy way to detect Java in IE. Hence we try to use the Deployment Toolkit first for all browsers, and if that fails, then we use any other methods that we know of.

[Java] We added ability to search mimetypes for the Java version if all other Java detection methods fail. This method would be used on Macintosh for Gecko browsers, and also IcedTea Java under Linux.

If you specify PluginDetect.isMinVersion(plugin) without the second argument, then the second argument is now assumed to be '0'.

You are now allowed to use a number for minVersion instead of just a string. This is used in PluginDetect.isMinVersion(plugin, minVersion)

Added a 'getVersionDone' property for each plugin to make it easier to keep track of running plugin.getVersion(). We only allow plugin.getVersion() to run once.



PluginDetect v0.3.0 (3/26/2008)

[Java, QuickTime, DevalVR] BugFix. We increase the version of PluginDetect to 0.3.0 to denote it's compatibility with Internet Explorer 8 (beta 1). PluginDetect was not previously compatible with IE 8 because I mixed up setAttribute() with setting a property.

[Java] For Java detection, I changed minIEver to 6 (from 5.5). Thus codebase detection technique will be used for IE 6 and higher, instead of IE 5.5 and higher. This is just a precaution, since IE 5.5 is probably not as reliable a browser for the codebase technique. I myself have never encountered a problem with it, however.

[Java] Also, I changed the JavaVersions array for searchAXOJavaPlugin() to -
JavaVersions: ["1.7.1.16", "1.6.1.16", "1.5.0.16", "1.4.2.13", "1.3.1.18"]
JavaVersions is now only used for IE < minIEver. So, it is used for IE 5 & IE 5.5.
It is unlikely that Java 1.8 will be used by IE 5.5 (Win 98) so that is not a problem.

[Silverlight/WMP] For Silverlight/Windows Media Player Firefox plugin, when inserting an object tag into <body>, I use <div><object></object></div> instead of just <object><object> so as to be strictly compatible with XHTML.

[Silverlight/WMP] For Silverlight/WMP Firefox plugin, in XHTML pages where the file extension is .xhtml and where the document.body does not exist yet, we cannot instantiate an <object>. Thus we cannot detect the plugin version in that case.

[WMP] For Windows Media Player Firefox Plugin, I avoid using data="data:" in the inserted <object></object> tag, or else Firefox 3 beta cannot get the version # of the plugin.

[WMP] We exclude older Gecko browsers from instantiating the WMP Firefox plugin to prevent a plugin crash. So, we exclude rv:0.x to rv:1.7
var q = (/rv\:(1\.[0-7]|0).*Gecko/).test(navigator.userAgent);

[Silverlight] For Silverlight in XHTML pages where the <body> tag does not exist yet for non-IE browsers, we cannot instantiate an <object> and detect any plugin version. In those cases we cannot tell whether the plugin is installed or not. And we cannot rely on the navigator.plugins array because that does not tell us if the plugin will run or not. Hopefully, the developers will fix the plugin so the
Silverlight plugin only shows up in the array when it is capable of running in that browser.

[Silverlight] Opera is buggy with Silverlight, and does not seem to work.
Opera cannot really interact with Silverlight using javascript yet.
Firefox 3 beta 4 is also buggy with Silverlight 2 beta 1, and does not seem to work. So for those browsers the plugin will show up as not installed.

[Silverlight] We exclude older Gecko browsers from seeing the Silverlight plugin to prevent browser crash.

[Silverlight] Silverlight detection may show that installed/enabled = false, but version = some #. This means that Silverlight is installed on your system, but does not seem to be compatible with the browser (ie. Javascript does not interact with Silverlight in this bropwser, Or Silverlight just will not run at all.) We assume that you do not have the case where web page = XHTML and document.body is null.



PluginDetect v0.2.2

Added support for Microsoft's Silverlight plugin.



PluginDetect v0.2.1

[WMP] Updated WMP detection for the new WMP Firefox Plugin The navigator array data is somewhat different.
The new info is -

description: np-mswmp
name: Microsoft® Windows Media Player Firefox Plugin

The old WMP plugin for Firefox was -

description: Npdsplay dll
name: Windows Media Player Plug-in Dynamic Link Library

The main difference is the change from "Plug-in" to "Plugin"

Also, we now attempt to get the WMP version info for the Firefox Plugin.

[WMP] Bugfix. In the WMP detector, is this line a bug ?
$.hasMimeType(['Flip4Mac', 'Windows', 'Media'], false)
Changed it to $.findNavPlugin(['Flip4Mac', 'Windows', 'Media'], false)



PluginDetect v0.2.0

[Java] Look for Java 1.4.2_11 Plug-in (Cocoa) etc... in Safari/Mac for MacOSX 10.2/10.3
So generically we search for Java \d Plugin-in (Cocoa).


PluginDetect v0.1.9

$.head = document.getElementsByTagName('head')[0] is now once again only used by Internet Explorer.

[Java] The Gecko crash bug for java.lang.System now uses the createEvent() method to force an event to fire on a dummy div element. It is no longer needed to append anything to the <head> in order to force an event to fire.



PluginDetect v0.1.8

Bug fix - $.head = document.getElementsByTagName('head')[0] was only defined for IE, but it is also being used by Gecko for Java detection, so I had to fix this.

Changed the compareNums() routine to be able to compare 2 numbers that have different numbers of digits.



PluginDetect v0.1.7

[Java] Found a better way to deal with the Gecko crash bug that occurs when accessing window.java.lang.System when Java is not installed. Instead of forcing a web page to reload when a crash occurs, we make the crash occur inside an event handler. The main javascript thread does not crash if the event handler crashes.

[Java] Safari 9.0-9.1 and MacIntel has a Java bug. Java does not run properly. Also, java.lang will crash the browser. So, we just say that Java not installed - even though the result is incorrect, at least the browser will not crash.



PluginDetect v0.1.6

Bug fix. $vbscript variable was always false. Fixed so that the script detects vbscript, and if present will set $vbscript = true

[Java] Added logic to make Firefox less likely to crash when Java not installed and we try to use window.java.lang.System.getProperty. We simply look at the mimetype application/x-java-vm. For Firefox in Rosetta mode on Intel/Mac we have to force a page reload since it is impossible to avoid the crash while trying to find the java version.

[QuickTime] Bugfix: For Safari/MacIntel, the Flip4Mac plugin confused the QuickTime plugin detection. So, for QuickTime detection we now have to check for "QuickTime" and "Plug-in".



PluginDetect v0.1.5

In hasMimeType() method, we now only require that the description OR the name is present, to verify the mimetype. This is a somewhat less strict requirement. I saw a case for QuickTime in Firefox on MacOSX where there was a mimetype and name property, but no description property.

In findNavPlugin() method, we now check for keyword(s) + num, or num + keyword(s) in the navigator array. This is slightly more strict than what we had before, where we checked for a num ANYWHERE in the string, even if that num was between 2 keywords.
The difference is that if we are looking for ['Java', 'Plug-in'] that the number is NOT permitted to be between Java and Plugin. It must come before 'Java' or after 'Plug-in'. Again, in Firefox on MacOSX for Java this change became necessary.



PluginDetect v0.1.4

Added VBScript to insert/delete object tags for Internet Explorer. If VBScript is not installed, then Javascript is used as a backup to insert/delete object tags (but Javascript requires the use of CollectGarbage() - which is not an official javascript method, it is Microsoft specific ). The reason for using VBScript is that it does not need a CollectGarbage() routine - it does not accumulate garbage the way javascript does.
We try to avoid using Javascript for the codebase detection method specifically because Microsoft recommends that we NOT use CollectGarbage().



Top of Page