[pluggerrc changes not read] Plugin caching preventing dynamic mime types through NP_GetMIMEDescritpion

RESOLVED WONTFIX

Status

()

Core
Plug-ins
P2
normal
RESOLVED WONTFIX
16 years ago
4 years ago

People

(Reporter: Dmitry Burstein, Unassigned)

Tracking

({relnote, topembed-})

Trunk
relnote, topembed-
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PL2:P2][Plug-in Mgr] [WORKAROUND: cause the timestamp of any plugin library to change])

(Reporter)

Description

16 years ago
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

16 years ago
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

16 years ago
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.

(Reporter)

Comment 3

16 years ago
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

16 years ago
you are right, lets keep this as mozilla bug.
Assignee: av → serge

Comment 5

15 years ago
*** Bug 135972 has been marked as a duplicate of this bug. ***

Comment 6

15 years ago
per serge's and dmitry's comments, confirming bug.

anthonyd
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → mozilla1.0.1

Comment 7

15 years ago
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?
Keywords: 4xp, relnote
OS: Linux → All
Hardware: PC → All
Summary: reloading of plugger definitions → [pluggerrc changes not read] Plugin caching preventing dynamic mime types through NP_GetMIMEDescritpion

Comment 8

15 years ago
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

15 years ago
Prefs with the list of dont-cache plugins would help.

Comment 10

15 years ago
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

15 years ago
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

15 years ago
>What if the name of such a file is dynamic?
we'll go with "do not cache" prefs for such plugin

Comment 13

15 years ago
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

15 years ago
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

15 years ago
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

15 years ago
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

15 years ago
Maybe we could have a pref which lists plugins that are not going to be "cached"?
Priority: -- → P2
Whiteboard: WORKAROUND: cause the timestamp of any plugin library to change

Comment 18

15 years ago
moving to future until we review open bug list
Target Milestone: mozilla1.0.1 → Future

Comment 19

15 years ago
This issue really needs to be addressed across all platforms and this should be
part of the plug-in manager work.
Whiteboard: WORKAROUND: cause the timestamp of any plugin library to change → [PL2:P2][Plug-in Mgr] [WORKAROUND: cause the timestamp of any plugin library to change]
Target Milestone: Future → mozilla1.2alpha

Updated

15 years ago
Target Milestone: mozilla1.2alpha → mozilla1.2beta

Comment 20

15 years ago
batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Keywords: topembed

Updated

15 years ago
Target Milestone: mozilla1.2beta → mozilla1.3beta

Updated

15 years ago
Keywords: topembed → topembed-

Updated

15 years ago
Blocks: 170349

Updated

15 years ago
Blocks: 176349

Updated

15 years ago
Blocks: 133816

Comment 21

15 years ago
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?
Target Milestone: mozilla1.3beta → ---
Assignee: srgchrpv → nobody
QA Contact: shrir → plugins
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.