This issue is being split out from http://bugzilla.mozilla.org/show_bug.cgi? id=37504 The way mozilla currently populates the list of installed plugins is by iterating thru the files in the nn4x and mozilla plugins directories: doing a name check on the file, loading those files that pass and querying the module for mimetype information. That check is limited to plugin modules whose filename begins with 'np'. But it is possible to build and instantiate xpcom plugins that do not reside in modules that start with 'np'. Further, xpcom plugins can be installed anywhere - not just in a mozilla directory (at least in Win32). It is possible on Win32 to install a stealth plugin - one that is not reflected via the navigator.plugins array but can nonetheless be instantiated - ie a properly registered xpcom plugin installed in a non-mozilla directory. The plugin discovery code needs to be rewritten to take into account xpcom plugins. One possibility is to query the registry for components that use NS_INLINE_PLUGIN_PROGID_PREFIX as a prefix to their progID (xpcom plugins are instantiated based on a progID of NS_INLINE_PLUGIN_PROGID_PREFIX + embed tag specified mimetype).

Adding http://bugzilla.mozilla.org/show_bug.cgi?id=36666 as a dependency of this since it deals with NS_INLINE_PLUGIN_PROGID_PREFIX.

Proposed solution to http://bugzilla.mozilla.org/show_bug.cgi?id=45698 addresses this problem. *** This bug has been marked as a duplicate of 45698 ***

mass duplicate verifications . For filtering purposes, pls use keywd "massdupverification"