As described in bug 236195, it is necessary to delete the plugin registration information so that mozilla will update its about:plugins list to reflect current filesystem reality. There are two common instances where this is necessary: 1. trying to get Adobe Acrobat to launch only as a separate helper application, not a browser plugin. Deleting nppdf32.dll from wherever you find it is not sufficent; I found that I must also delete: pluginreg.dat registry.dat from Documents and Settings\USER\Application Data\Mozilla\Profiles so that mozilla rebuilds its plugin information, doesn't discover the acrobat plugin dll anywhere, and doesn't attempt to launch a non-existent plugin contrary to user preferences based on its stupid-for-speed handling of mimetype handler information (see bug 58554). 2. Realvideo plugins. You upgrade mozilla. Realvideo plugin always stops working, presumably because mozilla installer treats real plugins as unknowns and trashes something. But about:plugins in the new mozilla tells you that realvideo is installed, because mozilla plugin registry information hasn't changed. Simple user fix here is to reinstall Real after you've upgraded mozilla. That is, reinstall ALL of Real, because there's no easy way to just reinstall the browser plugins. This is painful, and discourages users from upgrading mozilla. At the very least, about:plugins needs a 'Check these plugins are installed' button at top of page that manually rebuilds the entire plugins list from scratch and tells you what's changed. Ideally, this check and rebuild-if-necessary would be automatically done every time mozilla is launched; if the plugin isn't available, simply don't list it. Increased launch time should not be an issue here; being stupid-for-speed is still, ultimately, being stupid, and the user workarounds and are nonobvious, even once the user gets as far as realising that about:plugins is lying to him.
have you tried shift-reload on the about plugins page?
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20040910 As of Quicktime 6.5.2, the Quicktime plugin MIME settings are stored in ~/Library/Preferences/com.apple.quicktime.plugin.preferences.plist. Consistent with this bug, concerning the updating of pluginreg.dat, changes to the Quicktime plugin's MIME settings are not reflected in pluginreg.dat. See Bug 194986 Comment #5 by me for further details.
Also see bug 313700. This affects all platforms, afaict. Peter, are you still looking at / working on this?
OS: Windows 2000 → All
Hardware: PC → All
JST - have some time for this?
Would love to have this for the release - but since it is not a regression, top crash, or problem with new feature taking off he blocking list for now. JST please re-nom once you take a look if there is a reasonable fix.
Flags: blocking1.8.1+ → blocking1.8.1-
Is this still an issue ? Looks like it works for me with a current trunk build
about:plugins works fine for run-time removal/adding/... of plugins in current versions.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.