Identity API: defer loading component app

Identity API: do not load component app at startup

The scope approval component app's background script doesn't need to be running until the Identity API invokes the dialog, so there is no need to start the app when Chrome starts.

BUG=244220
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=202970

[Michael Courage, 2013-05-28 23:19:22]

This change fixes the memory regression described in crbug.com/244220. 

It seems a little worrisome to me that it is necessary to defer loading though.
It seems like having a background script in my component app makes a big (10+
MB) difference in memory usage as measured by this test. It seems to me like
either there is something wrong with the measurement, or that background scripts
impact users more than we'd probably like. (The regression reproduces even if my
background script is empty, but not if I remove it from the manifest.)

Either way, I'd like to land this change now to unblock the rest of the identity
API work.

[Matt Perry, 2013-05-29 00:39:28]

https://codereview.chromium.org/15892012/diff/1/chrome/browser/extensions/api...
File chrome/browser/extensions/api/identity/web_auth_flow.cc (right):

https://codereview.chromium.org/15892012/diff/1/chrome/browser/extensions/api...
chrome/browser/extensions/api/identity/web_auth_flow.cc:73: static bool
is_component_loaded = false;
This isn't multi-profile safe.

[Michael Courage, 2013-05-29 00:49:37]

https://codereview.chromium.org/15892012/diff/1/chrome/browser/extensions/api...
File chrome/browser/extensions/api/identity/web_auth_flow.cc (right):

https://codereview.chromium.org/15892012/diff/1/chrome/browser/extensions/api...
chrome/browser/extensions/api/identity/web_auth_flow.cc:73: static bool
is_component_loaded = false;
On 2013/05/29 00:39:28, Matt Perry wrote:
> This isn't multi-profile safe.

Good point. Is it reasonable/cheap to just do this unconditionally? It looked to
me like a lot of stuff was happening behind that Add call, so I threw in this
conditional. Seems like I should use a profile keyed service unless there is
some simpler way.

[Matt Perry, 2013-05-29 00:53:38]

https://codereview.chromium.org/15892012/diff/1/chrome/browser/extensions/api...
File chrome/browser/extensions/api/identity/web_auth_flow.cc (right):

https://codereview.chromium.org/15892012/diff/1/chrome/browser/extensions/api...
chrome/browser/extensions/api/identity/web_auth_flow.cc:73: static bool
is_component_loaded = false;
On 2013/05/29 00:49:37, Michael Courage wrote:
> On 2013/05/29 00:39:28, Matt Perry wrote:
> > This isn't multi-profile safe.
> 
> Good point. Is it reasonable/cheap to just do this unconditionally? It looked
to
> me like a lot of stuff was happening behind that Add call, so I threw in this
> conditional. Seems like I should use a profile keyed service unless there is
> some simpler way.

This will actually cause the app to reload, which it's probably best to avoid.
Can you use ComponentLoader::Exists? You need the app ID, but that should be
known.

[Michael Courage, 2013-05-29 01:49:53]

https://codereview.chromium.org/15892012/diff/1/chrome/browser/extensions/api...
File chrome/browser/extensions/api/identity/web_auth_flow.cc (right):

https://codereview.chromium.org/15892012/diff/1/chrome/browser/extensions/api...
chrome/browser/extensions/api/identity/web_auth_flow.cc:73: static bool
is_component_loaded = false;
ComponentLoader::Exists will do the trick, thanks.

It occurs to me that I really ought to put this code in
https://codereview.chromium.org/15897006/, which is where WebAuthFlow will
actually make use of the component app. I'll do that and just keep this CL
focused on fixing the memory issue.

[Matt Perry, 2013-05-29 01:55:37]

lgtm

[Matt Perry, 2013-05-29 01:55:48]

oh, update the CL description

[commit-bot: I haz the power, 2013-05-29 17:47:29]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/courage@chromium.org/15892012/10001

[commit-bot: I haz the power, 2013-05-29 21:11:39]

Change committed as 202970