282942 - Plugin manager's reloadPlugins method lies

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect)

Description

[Boris Zbarsky [:bzbarsky]]

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

Comment 1

[Boris Zbarsky [:bzbarsky]]

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

[Benjamin Smedberg]

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.