Can't we blacklist nspluginwrapper, and use the same logic that it uses to find the real plugins?
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 -~----------~----~----~----~------~----~------~--~---
