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)

defect
Not set
critical

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.
Blocks: 227833
have you tried shift-reload on the about plugins page?
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.
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
Depends on: 313700
JST - have some time for this?
Flags: blocking1.8.1+
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-
QA Contact: plugins
Is this still an issue ?
Looks like it works for me with a current trunk build
Flags: needinfo?(L.Wood)
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
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.