Issue metadata
Sign in to add a comment
|
Built-in extensions should not require a first-run process |
||||||||||||||||||
Issue descriptionOn first run (and upgrades) we start extensions to register their background events and such. We do this also for built-in extensions like the settings page and various bits of code that back services like text-to-speech. This code slows down startup considerably on the critical first run, and also since Chrome updates itself a lot, you'll also hit this more often than you may think. On my linux desktop (no corp policy) I saw 13 processes total on first run on a clean profile. These built-in extensions can be registered without starting processes. In browser/extensions/component_extensions_whitelist we have a list of built-in extensions with a locked-down owners list to prevent regressions of extensions. My idea is to add to this list the permissions and registrations required for each built-in extension statically, and then skip the normal launch-an-extension-process registration for those extensions. I think it would be beneficial if the permissions and event lists were also in the locked-down directory so we can keep a handle on what types of events teams are listening for that will require extension process launches.
,
May 27 2016
,
May 31 2016
,
Feb 13 2017
,
Feb 23 2017
Devlin: How would you feel about adding a component-extension-specific section to the manifest that describes the events the extension wants to handle, rather than baking that into the whitelist in Chrome?
,
Jan 10
Downgrading P2s that haven't been modified in more than 6 months, which have no component or owner. |
|||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||
Comment 1 by grt@chromium.org
, Mar 3 2016