Do not create login items if the user deleted a previous one.

Do not create login items if the user deleted a previous one.

Added a new kUserRemovedLoginItem pref that is used to track if the user has
previously removed a login item for chrome. This is so we don't keep re-creating
the login item every time the user enables/installs a background app if they
have indicated that they don't want chrome to open at login.

BUG=140017
TEST=Install background app on mac, uncheck "Open at Login" checkbox in dock menu, disable and re-enable the app via Tools->Extension, make sure Open at Login checkbox does not get re-enabled.


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=151102

[Andrew T Wilson (Slow), 2012-08-08 00:11:16]

Dmitry: PTAL

[Dmitry Titov, 2012-08-09 18:22:23]

I must say our method of detecting user actions is sketchy... But nothing better
coms to mind :-(

One note though:

http://codereview.chromium.org/10823221/diff/1/chrome/browser/background/back...
File chrome/browser/background/background_mode_manager_mac.mm (right):

http://codereview.chromium.org/10823221/diff/1/chrome/browser/background/back...
chrome/browser/background/background_mode_manager_mac.mm:34:
BrowserThread::PostTask(BrowserThread::UI, FROM_HERE,
So the detection of the user action (when user clears the login item) is only
done when the count of installed background apps touches zero.

I can think of at least one possibility to override user choice, at least w/o
inspecting a lot of code: If there is a quick sequence of disable/enable some
background apps so the counter goes to 0 and back, the tasks with
DisableLaunchOnStartupCallback/EnableLaunchOnStartupCallback can be queued
before the task that sets up the prefs::kUserRemovedLoginItem has an opportunity
to run. Who knows, maybe Sync can do that...

Maybe a local static boolean flag can help here, to keep the just-discovered
state? It doesn't even has to be synchronized...

[Andrew T Wilson (Slow), 2012-08-10 00:10:11]

Added the debug code you requested. PTAL.

[Dmitry Titov, 2012-08-10 00:21:33]

lgtm

[commit-bot: I haz the power, 2012-08-10 03:30:09]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/atwilson@chromium.org/10823221/3002

[commit-bot: I haz the power, 2012-08-10 03:30:12]

Presubmit check for 10823221-3002 failed and returned exit status 1.


Running presubmit commit checks ...

** Presubmit ERRORS **
Missing LGTM from an OWNER for files in these directories:
    chrome

Was the presubmit check useful? Please send feedback & hate mail to
maruel@chromium.org!

[Andrew T Wilson (Slow), 2012-08-10 03:58:09]

Scott, can you LGTM my changes to chrome/common/pref_names.h/cc? CQ won't let me
land changes to chrome/common without an OWNER from chrome/

[sky, 2012-08-10 16:12:34]

LGTM

[commit-bot: I haz the power, 2012-08-10 16:13:45]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/atwilson@chromium.org/10823221/3002

[commit-bot: I haz the power, 2012-08-10 19:22:43]

Change committed as 151102