Closed
Bug 236201
Opened 20 years ago
Closed 11 years ago
about:plugins lies to user about available plugins
Categories
(Core Graveyard :: Plug-ins, defect)
Core Graveyard
Plug-ins
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: L.Wood, Assigned: peterlubczynski-bugs)
References
Details
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.
Reporter | ||
Comment 2•20 years ago
|
||
If you view source on about:plugins, you will see that the about:plugins page is generated dynamically by javascript. Shift-reload has no effect.
bah, who broke that? javascript:navigator.plugins.refresh(true); from about:plugins
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.
Comment 5•19 years ago
|
||
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
Comment 7•18 years ago
|
||
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-
Updated•15 years ago
|
QA Contact: plugins
Comment 9•11 years ago
|
||
Is this still an issue ? Looks like it works for me with a current trunk build
Flags: needinfo?(L.Wood)
Comment 10•11 years ago
|
||
about:plugins works fine for run-time removal/adding/... of plugins in current versions.
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: needinfo?(L.Wood)
Resolution: --- → WORKSFORME
Comment hidden (spam) |
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•