Last Comment Bug 125469 - [pluggerrc changes not read] Plugin caching preventing dynamic mime types through NP_GetMIMEDescritpion
: [pluggerrc changes not read] Plugin caching preventing dynamic mime types thr...
Status: RESOLVED WONTFIX
[PL2:P2][Plug-in Mgr] [WORKAROUND: ca...
: relnote, topembed-
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: All All
: P2 normal with 4 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Benjamin Smedberg [:bsmedberg]
Mentors:
: 135972 (view as bug list)
Depends on:
Blocks: 133816 170349 grouper
  Show dependency treegraph
 
Reported: 2002-02-14 03:42 PST by Dmitry Burstein
Modified: 2013-01-16 06:22 PST (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Dmitry Burstein 2002-02-14 03:42:53 PST
Hi!

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.
Comment 1 av (gone) 2002-02-14 10:51:17 PST
How exactly do you reload the plugger definitions? And when did this start 
happen?

My suspicion is our new change detection mechanism which does not count 
non-plugin files and non-plugin folders. 
Comment 2 serge (gone) 2002-02-14 15:24:49 PST
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.

Comment 3 Dmitry Burstein 2002-02-16 14:51:22 PST
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.
Comment 4 serge (gone) 2002-02-18 15:30:03 PST
you are right, lets keep this as mozilla bug.
Comment 5 Andrew Schultz 2002-04-07 06:27:37 PDT
*** Bug 135972 has been marked as a duplicate of this bug. ***
Comment 6 anthonyd 2002-05-05 17:21:56 PDT
per serge's and dmitry's comments, confirming bug.

anthonyd
Comment 7 Peter Lubczynski 2002-05-05 17:50:32 PDT
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? 

Ideas?
Comment 8 Suresh Duddi (gone) 2002-05-06 13:14:31 PDT
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.
Comment 9 av (gone) 2002-05-06 13:55:31 PDT
Prefs with the list of dont-cache plugins would help.
Comment 10 serge (gone) 2002-05-06 14:32:36 PDT
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 
like:
user_pref("plugin.files.dependancies.for.plugin_file_name", list_of_file);
in plugger linux case it would be
user_pref("plugin.files.dependancies.for.plugger4.so", 
"~/.mozilla/plugins/plugger-4.0:~mozilla/plugins/pluggerrc");
Comment 11 av (gone) 2002-05-06 16:04:36 PDT
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?
Comment 12 serge (gone) 2002-05-06 16:21:07 PDT
>What if the name of such a file is dynamic?
we'll go with "do not cache" prefs for such plugin
Comment 13 Peter Lubczynski 2002-05-06 18:17:39 PDT
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?
Comment 14 Istvan Toth 2002-06-06 04:31:29 PDT
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.
Comment 15 Dan Allen 2002-07-01 04:20:34 PDT
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.
Comment 16 Dan Allen 2002-07-01 04:21:32 PDT
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.
Comment 17 Peter Lubczynski 2002-07-01 11:50:33 PDT
Maybe we could have a pref which lists plugins that are not going to be "cached"?
Comment 18 rubydoo123 2002-07-01 17:13:56 PDT
moving to future until we review open bug list
Comment 19 rubydoo123 2002-07-23 10:47:44 PDT
This issue really needs to be addressed across all platforms and this should be
part of the plug-in manager work.
Comment 20 Marek Z. Jeziorek 2002-09-13 09:55:27 PDT
batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Comment 21 Francois Gouget 2002-11-15 11:36:51 PST
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?

Note You need to log in before you can comment on or make changes to this bug.