This is much needed, thanks for working on it :) Some notes: -Putting it in a url, but not having a menu item, removes much of the benefit since only a tiny percentage would be able to use it. -Checking that each plugin is up to date should be automatic and enabled for all users, just like our plugin installer is automatic. I don't see the benefit of having that functionality be listed as a "plugin", especially since that can't be completely done inside an NPAPI plugin.
Can you put this information in a mini design doc somewhere online? Also things like exactly how you propose to implement this, and the future features (i.e. disabling plugins that have big security holes, asking the user to update etc...) On Mon, Dec 7, 2009 at 11:08 AM, Panayiotis <panayio...@google.com> wrote: > Hello, we are a small group of Googlers who'd like to volunteer our 20% > time to work on plugin management, and eventually plugin update in Chromium. > At first we'd like to start working only on management. We'd appreciate if > you could review our proposal and provide feedback. > > Thanks, > Panayiotis, Noe, Nav. > > > *Plugin Manager UI Proposal * > > *Purpose*: UI for managing (enabling/disabling) plugins in Chromium. > > *Background*: There's a lot of reasons why this would be desirable, most > are reported in http://code.google.com/p/chromium/issues/detail?id=736, > major ones include security and performance > > *Suggested solution: * > > The User Interface could look a lot like chrome://extensions. We could use > for example *chrome://plugins*/ for its url. A user would have to type the > url to get to it, we would not link to it from any menu. Very similar to > chrome://extensions, it would be a table of all plugins, with ability to > enable/disable plugins. A mockup is attached. > > All plugins, plugin name, plugin description, plugin version (see below) > and full filename of the plugin on the filesystem would be listed. Disabled > plugins look like disabled extensions and have an "enable" link, enabled > plugins have a "disable" link. > > *Non-goals:* > > - We don't want to be able to enable/disable plugins per-site/ per-tab > at this point. > - There won't be any notification to the user that a plugin was > attempted to be used -- this can be hard to detect because many pages use > JS > to see if the plugin is installed and show different content if it's not. > It's not impossible, but we think we shouldn't aim for this in the first > iteration. > > *Alternative ideas we considered:* > > - Modify about:plugins for this purpose. That page is a simple > javascript page that iterates over navigator.plugins. Similar to other > about: pages it doesn't have access to chrome internals. We feel > chrome://plugins follows the model of chrome://extensions better, in that > this page cannot be inspected and allows the user to modify state of the > browser. > - Have a popup window similar to Firefox's Add-on manager. We feel > mimicing chrome://extensions is going to be more consistent, besides, > having > it be a url allows you to load it in a tab. > - Add the plugins to chrome://extensions -- we can do that too, we'll > let Chromium devs chime in on what's the preferred option here. > > *Implementation details:* > > - Modify mostly PluginService (chrome/browser/plugin_service.cc) > - Will store state in the sqlite database, per user. > - A plugin is identified by its path in the filesystem. Different paths > are considered different plugins. > - Once a plugin is disabled, all subsequent calls to create a plugin > instance will fail. Similarly for enabling. Pages that have the plugin > already loaded should still work. > > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
