Closed
Bug 282942
Opened 19 years ago
Closed 11 years ago
Plugin manager's reloadPlugins method lies
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: bzbarsky, Unassigned)
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
Reporter | ||
Comment 1•19 years ago
|
||
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•11 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
Closed: 11 years ago
Resolution: --- → WONTFIX
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
•