I noticed that in order to reload the definitions of the plugger after i change
the /etc/pluggerrc-4.0 file, i need to perform a date update to the plugger
itself: "touch /usr/lib/mozilla/plugins/plugger.so". Otherwise, the definitions
remain inchaneged even when restarting mozilla browther.
How exactly do you reload the plugger definitions? And when did this start
My suspicion is our new change detection mechanism which does not count
non-plugin files and non-plugin folders.
that is how it suppose to work, all plugins info is cached into
~/.mozilla/appreg file, and cache is getting updated when
cached plugin's last modified time does not match with current.
In the case of plugger it not enough merely to check the plugin's modification
time, because the plugger itself has an rc file holdig its configuration
(/etc/pluggerrc or /etc/pluggerrc-4.0). So the cache file has to be updated when
the rc file was modified either.
you are right, lets keep this as mozilla bug.
*** Bug 135972 has been marked as a duplicate of this bug. ***
per serge's and dmitry's comments, confirming bug.
I think this is a serious bug. Our new "plugin caching" depends on file mod time
of the library (.so in this case) so it's not going to call
NP_GetMIMEDescription unless the library has been 'touched'.
BTW, Mac has this same problem, so changing platform to All.
I'm not sure what approach we can take here without hurting performance or
breaking backwards compatibility. Maybe some kind of pref?
Bummer. Maybe we can ask the plugin if it is a dynamic mimetype provider and
disable cache for it. But then this would be a new call and old plugins dynamic
mimetype plugins will still be cached. If there arent a lot of these old plugins
that are dynamic mimetype (I am hoping so) we could check for them (a list
somewhere on disk) and not cache them.
Prefs with the list of dont-cache plugins would help.
Prefs with the list of dont-cache plugins would help
yeah, for plugins like QT on win32 which mimetypes setting I believe is saved in
system regestry and could be
configured from control panel,
but for plugins which read its setting from 2d file I would prefer something
in plugger linux case it would be
So you essentially suggest to add some non-dll files to the cache info? I am not
sure this is a good idea. What if the name of such a file is dynamic?
>What if the name of such a file is dynamic?
we'll go with "do not cache" prefs for such plugin
All plugins on UNIX use NP_GetMIMEDescription, some on Mac, and in the future I
can see Windows multi-user systems wanting this feature. I think it may be hard
to weed out the dynamic ones vs. the static ones.
I don't know too much about plugger, but I'm not too keen about including the
plugins filename in the pref name. What if the filename changes, like with a new
version? Is there something else we could key on?
Is there some other resource info that we can use rather than loading the library?
I've found this bug, too, my ideas:
The list of MIME types handled by plugger is read from the pluggerrc file,
that's the only place you could get the information from, apart from loading the
plugin, and I don't think that parsing that file from Mozilla is practical.
You could simply have a preference that adds a file to the list of plugin files
so that when that file changes, all plugins are re-queried about the supported
mime types. In the linux plugger case this would bear no major performance hit,
as the pluggerrc file changes very rarely.
The Linux distributions could ship their mozilla with this pref tuned to their
plugger version, and it would just work out of the box.
As for the name of pluggerrc changing, I don't think that's very likely, and the
distribution makers could easily follow that. I estimate that 98% of the plugger
plugins installed come default with the distribution. For thos who install
plugger from source, a waring could be added to the plugger package to change
the pref if they install in non-standard location.
I am not from codeweavers, merely a customer, but I have to report that this is
going to interfere with their progress...because people install the crossover
plugin from codeweavers and then they don't get any results because plugger is
hording the plugins away from the crossover...it says in the instructions for
the crossover to comment out the lines that have to do with quicktime and
microsoft files in /etc/pluggerrc, but this isn't going to work if mozilla
caches the pluggerrc stuff. I think that this problem could be very important
to them, that's all.
Maybe we could have a pref which lists plugins that are not going to be "cached"?
moving to future until we review open bug list
This issue really needs to be addressed across all platforms and this should be
part of the plug-in manager work.
batch: adding topembed per Gecko2 document
We have the same problem with CrossOver Plugin: our plugin is just a proxy that
turns around and loads the windows plugin. If we cannot do that for some reason
we return a dummy name/description in NP_GetMIMEDescription (returning NULL
causes some browsers to crash) and, as luck would have it, this data often gets
cached by Mozilla.
So for each of our problem resolution procedures we have to specify something
along the lines of: "and don't forget to do a touch /usr/lib/mozilla/npwine.*.so
to force Mozilla to refresh its plugin cache (adapt the path as necessary)".
We have a similar problem when a Windows plugin changes its list of supported
MIME types like QuickTime does if you go play with its preferences (it also
deletes/recreates its plugin libraries though currently we have no way to mirror
that action on our proxy plugin).
So overall the cache is quite annoying so we would be very interested if a
solution to this issue could be found.
The solution used by Netscape 4.x is to systematically query all plugins on
startup. It doesn't seem so bad. Maybe it would be even more acceptable if it
was done in the background?