Closed
Bug 125469
Opened 22 years ago
Closed 11 years ago
[pluggerrc changes not read] Plugin caching preventing dynamic mime types through NP_GetMIMEDescritpion
Categories
(Core Graveyard :: Plug-ins, defect, P2)
Core Graveyard
Plug-ins
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: DmitryBurstein, Unassigned)
References
Details
(Keywords: relnote, topembed-, Whiteboard: [PL2:P2][Plug-in Mgr] [WORKAROUND: cause the timestamp of any plugin library to change])
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.
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•22 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•22 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 5•22 years ago
|
||
*** Bug 135972 has been marked as a duplicate of this bug. ***
per serge's and dmitry's comments, confirming bug. anthonyd
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → mozilla1.0.1
Comment 7•22 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?
Comment 8•22 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 10•22 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•22 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•22 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•22 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•22 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•22 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•22 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•22 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•22 years ago
|
||
moving to future until we review open bug list
Target Milestone: mozilla1.0.1 → Future
Comment 19•22 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•22 years ago
|
Target Milestone: mozilla1.2alpha → mozilla1.2beta
Comment 20•22 years ago
|
||
batch: adding topembed per Gecko2 document http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Keywords: topembed
Updated•22 years ago
|
Target Milestone: mozilla1.2beta → mozilla1.3beta
Updated•22 years ago
|
Comment 21•22 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?
Updated•19 years ago
|
Target Milestone: mozilla1.3beta → ---
Updated•19 years ago
|
Assignee: srgchrpv → nobody
QA Contact: shrir → plugins
Updated•11 years ago
|
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
•