Plugin manager's reloadPlugins method lies

RESOLVED WONTFIX

Status

()

Core
Plug-ins
RESOLVED WONTFIX
14 years ago
6 years ago

People

(Reporter: bz, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

See comments in bug 273785.  Basically, the plugin manager is returning NS_OK
for me even though there are no new plugins; that sends the first patch in that
bug into an infinite loop.

I have $MOZ_PLUGIN_PATH set to /home/bzbarsky/plugins and the files in that
directory are:

flashplayer.xpt    libjavaplugin_oji.so@  nppdf.so
libflashplayer.so  mplayerplug-in.so      rpnp.so
So the problem seems to be that the libjavaplugin_oji.so symlink is pointing to
a nonexistent file.  So in nsPluginHostImpl::ScanPluginsDirectory when we do 

4865     nsPluginTag *pluginTag =
RemoveCachedPluginsInfo(NS_ConvertUCS2toUTF8(pfd->mFilename).get());

we get back null.  That triggers us to claim that plugins have changed (since
here we have a file that doesn't correspond to a plugin).

So this will happen any time we have a file that isn't, say, a shared library
(since the fact that we got nothing out of it will never get cached).

Should we have some way to flag these files as "checked out and not plugin"
internally?  That is, should nsPluginTag support such a flag (and consumers be
changed to check it)?

Comment 2

6 years ago
I'm not sure whether the docs have changed, but currently the reloadPlugin method should succeed in all cases (whether or not new plugins are found). Going to call this WONTFIX, please reopen if necessary.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.