On Fri, Aug 28, 2009 at 11:03 AM, John Abd-El-Malek <[email protected]>wrote:
> Can't we blacklist nspluginwrapper, and use the same logic that it uses to > find the real plugins? Last time I looked, the way nspw works: for each wrapped plugin it installs a version of the nspw plugin into the 'normal' plugins directory, except each one of these is tagged with the hard-coded path to the original plugin. So it'd be nice to detect nspw plugins, and extract from there the path to the original plugins and try to load those. However 2 issues I can forsee: - nspw plugins try to look like regular plugins - I'm not sure the ABI nspw uses to embed the hard-coded path is stable. See http://svn.beauchesne.info/gwenole/projects/nspluginwrapper/trunk/src/npw-config.c?revision=881&view=markupfor the tool that generates it. Maybe my concerns are not founded, see the is_wrapper_plugin_handle function, it itself can read various versions. However if we're chrome 32 trying to use the 64-bit nspw plugins to find the original 32 bit ones, we'll need to manually read the elf, since dlopen will fail. Antoine > > On Fri, Aug 28, 2009 at 11:01 AM, Evan Martin <[email protected]> wrote: > >> >> Right now our plugin loading code matches Firefox in the search path >> order. >> 1 $MOZ_PLUGIN_PATH >> 2 ~/.mozilla/plugins >> 3 path_to_chrome_binary/plugins <- analogous to Firefox >> 4 /usr/lib/mozilla/plugins and related directories <- what Firefox uses >> >> On systems that have nspluginwrapper installed, they have an >> nspluginwrapper instance in the 4th directory and a copy of Flash >> (etc.) hidden off to the side. That means Chrome will also use >> nspluginwrapper, which is suboptimal: Chrome spawns a plugin process >> which loads nspluginwrapper which itself spawns another plugin >> process. >> >> It would be nice to not use nspluginwrapper, but we cannot just >> request people install plugins into the "normal" plugins directories, >> as you want other browsers (Firefox, etc.) to continue using >> nspluginwrapper. >> >> I propose the solution to this is to put Chrome-specific plugin >> directories at the front of the search path. Something like >> 1 ~/.config/google-chrome/plugins (not sure on this one... a bit >> weird to stick plugins in a "config" dir) >> 2 path_to_chrome_binary/plugins >> and then the Mozilla paths as before >> 1 $MOZ_PLUGIN_PATH >> 2 ~/.mozilla/plugins >> 4 /usr/lib/mozilla/plugins and related directories <- what Firefox uses >> >> Then people can install (symlink) the "real" plugins into the >> chrome-specific dirs if they want. >> Does that seem reasonable? >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
