Revert "Eliminate all code related to the AutomaticProfileResetter."

Revert "Eliminate all code related to the AutomaticProfileResetter."

This reverts commit:
  https://chromium.googlesource.com/chromium/src/+/93ea39da5423d641ecbc5687764f6b12972e302a.

Additionally, it also changes the |first_id| for the string resource group chrome/browser/browser_resources.grd / "includes", because the group has ran out of IDs.

BUG=370966
NOPRESUBMIT=true
R=asvitkine@chromium.org, dbeam@chromium.org, erg@chromium.org, gab@chromium.org, sky@chromium.org, vasilii@chromium.org

Committed: https://crrev.com/9d0221cd251502231877f943fa2872a2f92a5621
Cr-Commit-Position: refs/heads/master@{#295450}

[engedy, 2014-09-03 14:35:04]

engedy@chromium.org changed reviewers:
+ battre@chromium.org, gab@chromium.org, vasilii@chromium.org

[engedy, 2014-09-03 14:38:34]

@Dominic: please take a look at the whole thing, and let me know if you can
think of any pitfalls with re-adding potentially stale code.

@Vasilii: could you please take a look at:
  c/b/profile_resetter/*
  c/b/ui/webui/*
  c/b/r/options/*

@Gabriel: could you please take a look at:
  c/b/prefs/chrome_pref_service_factory.cc
to make sure that nothing will explode if I re-add an element, especially with
ENFORCE_ON_LOAD.

[gab, 2014-09-03 14:51:40]

https://codereview.chromium.org/533183002/diff/1/chrome/browser/prefs/browser...
File chrome/browser/prefs/browser_prefs.cc (left):

https://codereview.chromium.org/533183002/diff/1/chrome/browser/prefs/browser...
chrome/browser/prefs/browser_prefs.cc:228: const char
kProfileResetPromptMemento[] = "profile.reset_prompt_memento";
Shall we instead use a new pref name? I think it was particularly wrong
previously to use the same pref name for two different things in Local State and
Preferences.

I'd keep clearing this one and use two new names for the Local State and
Preferences prefs.

https://codereview.chromium.org/533183002/diff/1/chrome/browser/prefs/browser...
File chrome/browser/prefs/browser_prefs.cc (right):

https://codereview.chromium.org/533183002/diff/1/chrome/browser/prefs/browser...
chrome/browser/prefs/browser_prefs.cc:477: // key) go here.
Leave this as it had been fixed.

https://codereview.chromium.org/533183002/diff/1/chrome/browser/prefs/chrome_...
File chrome/browser/prefs/chrome_pref_service_factory.cc (right):

https://codereview.chromium.org/533183002/diff/1/chrome/browser/prefs/chrome_...
chrome/browser/prefs/chrome_pref_service_factory.cc:159:
PrefHashFilter::TRACKING_STRATEGY_ATOMIC
This should be okay; either it got cleared, or it still exists and has a valid
MAC (i.e. the last Chrome that ran had this as a protected pref).

Even safer/cleaner would be to use new pref names though IMO as suggested above.

[vasilii, 2014-09-04 11:51:29]

Rubber stamp
c/b/profile_resetter/ LGTM

[engedy, 2014-09-04 11:59:45]

https://codereview.chromium.org/533183002/diff/1/chrome/browser/prefs/browser...
File chrome/browser/prefs/browser_prefs.cc (left):

https://codereview.chromium.org/533183002/diff/1/chrome/browser/prefs/browser...
chrome/browser/prefs/browser_prefs.cc:228: const char
kProfileResetPromptMemento[] = "profile.reset_prompt_memento";
On 2014/09/03 14:51:39, gab wrote:
> Shall we instead use a new pref name? I think it was particularly wrong
> previously to use the same pref name for two different things in Local State
and
> Preferences.
> 
> I'd keep clearing this one and use two new names for the Local State and
> Preferences prefs.

For Profile Prefs, I think the current name is very descriptive, and could not
come up with anything better, therefore I would like to keep it. For Local
State, I have changed the name to be in plural. This means that the pref in
Profile Prefs would get resurrected.

WDYT?

https://codereview.chromium.org/533183002/diff/1/chrome/browser/prefs/browser...
File chrome/browser/prefs/browser_prefs.cc (right):

https://codereview.chromium.org/533183002/diff/1/chrome/browser/prefs/browser...
chrome/browser/prefs/browser_prefs.cc:477: // key) go here.
On 2014/09/03 14:51:39, gab wrote:
> Leave this as it had been fixed.

Done.

https://codereview.chromium.org/533183002/diff/1/chrome/browser/prefs/chrome_...
File chrome/browser/prefs/chrome_pref_service_factory.cc (right):

https://codereview.chromium.org/533183002/diff/1/chrome/browser/prefs/chrome_...
chrome/browser/prefs/chrome_pref_service_factory.cc:159:
PrefHashFilter::TRACKING_STRATEGY_ATOMIC
On 2014/09/03 14:51:39, gab wrote:
> This should be okay; either it got cleared, or it still exists and has a valid
> MAC (i.e. the last Chrome that ran had this as a protected pref).
> 
> Even safer/cleaner would be to use new pref names though IMO as suggested
above.

I went for a middle-ground solution, please see my response to the comment
before.

[gab, 2014-09-05 01:00:19]

SGTM, lgtm thanks!

https://codereview.chromium.org/533183002/diff/20001/chrome/common/pref_names.cc
File chrome/common/pref_names.cc (right):

https://codereview.chromium.org/533183002/diff/20001/chrome/common/pref_names...
chrome/common/pref_names.cc:197: };
git cl format?

Feels this should remain unindented.

https://codereview.chromium.org/533183002/diff/20001/chrome/common/pref_names...
chrome/common/pref_names.cc:1278: // reset prompt has already been shown to the
corresponding user (profile).
So this means the same thing as the individual per profile prefs? Can you
elaborate in this comment about the need for having both?

[engedy, 2014-09-05 11:45:46]

https://codereview.chromium.org/533183002/diff/20001/chrome/common/pref_names.cc
File chrome/common/pref_names.cc (right):

https://codereview.chromium.org/533183002/diff/20001/chrome/common/pref_names...
chrome/common/pref_names.cc:197: };
On 2014/09/05 01:00:19, gab wrote:
> git cl format?
> 
> Feels this should remain unindented.

Argh... yes. I have accidentally the whole thing. Undone.

https://codereview.chromium.org/533183002/diff/20001/chrome/common/pref_names...
chrome/common/pref_names.cc:1278: // reset prompt has already been shown to the
corresponding user (profile).
On 2014/09/05 01:00:19, gab wrote:
> So this means the same thing as the individual per profile prefs? Can you
> elaborate in this comment about the need for having both?

Done.

[engedy, 2014-09-05 11:59:03]

engedy@chromium.org changed reviewers:
+ asvitkine@chromium.org, dbeam@chromium.org, erg@chromium.org, sky@chromium.org

[engedy, 2014-09-05 11:59:04]

Dear Owners,

You have reviewed the CL removing this code
(https://codereview.chromium.org/271673006) ~1 month ago. This CL is reverting
that removal. Please let me know if you can think of anything specific I should
double-check to reduce the risk of resurrecting so much code (the resurrected
code will be initially disabled by a field trial). Then, PTAL for OWNERs'
approval:

@Dan:
  c/b/resources/options/
  c/b/ui/webui/

@Elliot:
  c/b/profiles

@Scott:
  c/a/generated_resources.grd
  c/b/browser_resources.grd
  c/b/ui/profile_reset_bubble.*
  c/b/ui/views/
  c/c/chrome_constants.*

@Alexei:
  histograms.xml

[Alexei Svitkine (slow), 2014-09-05 13:36:02]

lgtm

[Elliot Glaysher, 2014-09-05 17:08:18]

lgtm

[sky, 2014-09-05 19:08:17]

LGTM

[Dan Beam, 2014-09-05 19:21:45]

https://codereview.chromium.org/533183002/diff/40001/chrome/browser/resources...
File chrome/browser/resources/options/reset_profile_settings_banner.js (right):

https://codereview.chromium.org/533183002/diff/40001/chrome/browser/resources...
chrome/browser/resources/options/reset_profile_settings_banner.js:27:
this.showMetricName_ = 'AutomaticReset_WebUIBanner_BannerShown';
don't @override private members.  either change these to be @protected or create
accessors in SettingsBannerBase

https://codereview.chromium.org/533183002/diff/40001/chrome/browser/resources...
chrome/browser/resources/options/reset_profile_settings_banner.js:32:
this.setVisibilibyDomElement_ = $('reset-profile-settings-banner');
Visibiliby -> Visibility

https://codereview.chromium.org/533183002/diff/40001/chrome/browser/resources...
File chrome/browser/resources/options/settings_banner.css (right):

https://codereview.chromium.org/533183002/diff/40001/chrome/browser/resources...
chrome/browser/resources/options/settings_banner.css:5: /* These styles are used
bby both reset_profile_settings_banner.html and
bby -> by

https://codereview.chromium.org/533183002/diff/40001/chrome/browser/resources...
File chrome/browser/resources/options/settings_banner.js (left):

https://codereview.chromium.org/533183002/diff/40001/chrome/browser/resources...
chrome/browser/resources/options/settings_banner.js:6: // SettingsBannerBase.
Refactor this into automatic_settings_reset_banner.js.
why did you remove?  is this done?

https://codereview.chromium.org/533183002/diff/40001/chrome/browser/ui/webui/...
File chrome/browser/ui/webui/options/reset_profile_settings_handler.cc (right):

https://codereview.chromium.org/533183002/diff/40001/chrome/browser/ui/webui/...
chrome/browser/ui/webui/options/reset_profile_settings_handler.cc:30: :
automatic_profile_resetter_(NULL), has_shown_confirmation_dialog_(false) {
nit: \n after ,

https://codereview.chromium.org/533183002/diff/40001/chrome/browser/ui/webui/...
chrome/browser/ui/webui/options/reset_profile_settings_handler.cc:48:
automatic_profile_resetter_->ShouldShowResetBanner())
curlies

https://codereview.chromium.org/533183002/diff/40001/chrome/browser/ui/webui/...
chrome/browser/ui/webui/options/reset_profile_settings_handler.cc:93:
OnDismissedResetProfileSettingsBanner,
usually these methods are named HandleChromeSendName (e.g. for
chrome.send('chromeSendName'))

[engedy, 2014-09-10 13:46:26]

https://codereview.chromium.org/533183002/diff/40001/chrome/browser/resources...
File chrome/browser/resources/options/reset_profile_settings_banner.js (right):

https://codereview.chromium.org/533183002/diff/40001/chrome/browser/resources...
chrome/browser/resources/options/reset_profile_settings_banner.js:27:
this.showMetricName_ = 'AutomaticReset_WebUIBanner_BannerShown';
On 2014/09/05 19:21:45, Dan Beam wrote:
> don't @override private members.  either change these to be @protected or
create
> accessors in SettingsBannerBase

Done, made it @protected.

https://codereview.chromium.org/533183002/diff/40001/chrome/browser/resources...
chrome/browser/resources/options/reset_profile_settings_banner.js:32:
this.setVisibilibyDomElement_ = $('reset-profile-settings-banner');
Done, replaced 4 occurrences.

https://codereview.chromium.org/533183002/diff/40001/chrome/browser/resources...
File chrome/browser/resources/options/settings_banner.css (right):

https://codereview.chromium.org/533183002/diff/40001/chrome/browser/resources...
chrome/browser/resources/options/settings_banner.css:5: /* These styles are used
bby both reset_profile_settings_banner.html and
On 2014/09/05 19:21:45, Dan Beam wrote:
> bby -> by

Done.

https://codereview.chromium.org/533183002/diff/40001/chrome/browser/resources...
File chrome/browser/resources/options/settings_banner.js (left):

https://codereview.chromium.org/533183002/diff/40001/chrome/browser/resources...
chrome/browser/resources/options/settings_banner.js:6: // SettingsBannerBase.
Refactor this into automatic_settings_reset_banner.js.
On 2014/09/05 19:21:45, Dan Beam wrote:
> why did you remove?  is this done?

This would have been necessitated by the very removal of the
ResetProfileSettingsBanner that we are now reverting.

https://codereview.chromium.org/533183002/diff/40001/chrome/browser/ui/webui/...
File chrome/browser/ui/webui/options/reset_profile_settings_handler.cc (right):

https://codereview.chromium.org/533183002/diff/40001/chrome/browser/ui/webui/...
chrome/browser/ui/webui/options/reset_profile_settings_handler.cc:30: :
automatic_profile_resetter_(NULL), has_shown_confirmation_dialog_(false) {
On 2014/09/05 19:21:45, Dan Beam wrote:
> nit: \n after ,

Done.

https://codereview.chromium.org/533183002/diff/40001/chrome/browser/ui/webui/...
chrome/browser/ui/webui/options/reset_profile_settings_handler.cc:48:
automatic_profile_resetter_->ShouldShowResetBanner())
On 2014/09/05 19:21:45, Dan Beam wrote:
> curlies

Done.

https://codereview.chromium.org/533183002/diff/40001/chrome/browser/ui/webui/...
chrome/browser/ui/webui/options/reset_profile_settings_handler.cc:93:
OnDismissedResetProfileSettingsBanner,
On 2014/09/05 19:21:45, Dan Beam wrote:
> usually these methods are named HandleChromeSendName (e.g. for
> chrome.send('chromeSendName'))

True. However, the messages above also use this different convention, and I
wanted to be consistent with those. I am happy to address all 3 in a follow-up
CL if you feel strongly about this.

[Dan Beam, 2014-09-10 19:13:37]

lgtm w/nit

https://codereview.chromium.org/533183002/diff/60001/chrome/browser/resources...
File chrome/browser/resources/options/settings_banner.js (right):

https://codereview.chromium.org/533183002/diff/60001/chrome/browser/resources...
chrome/browser/resources/options/settings_banner.js:49: setVisibilityDomElement:
null,
nit: visibilityDomElement (prefixing with "set" definitely sounds like this is
an accessor)

[Dan Beam, 2014-09-10 19:14:44]

slgtm

https://codereview.chromium.org/533183002/diff/40001/chrome/browser/ui/webui/...
File chrome/browser/ui/webui/options/reset_profile_settings_handler.cc (right):

https://codereview.chromium.org/533183002/diff/40001/chrome/browser/ui/webui/...
chrome/browser/ui/webui/options/reset_profile_settings_handler.cc:93:
OnDismissedResetProfileSettingsBanner,
On 2014/09/10 13:46:26, engedy wrote:
> On 2014/09/05 19:21:45, Dan Beam wrote:
> > usually these methods are named HandleChromeSendName (e.g. for
> > chrome.send('chromeSendName'))
> 
> True. However, the messages above also use this different convention, and I
> wanted to be consistent with those. I am happy to address all 3 in a follow-up
> CL if you feel strongly about this.

I don't say I feel *strongly* as there is a bit of other code that doesn't
follow this rule.  Would probably be more worthwhile just to fix this all at
once.

[engedy, 2014-09-11 11:51:15]

https://codereview.chromium.org/533183002/diff/60001/chrome/browser/resources...
File chrome/browser/resources/options/settings_banner.js (right):

https://codereview.chromium.org/533183002/diff/60001/chrome/browser/resources...
chrome/browser/resources/options/settings_banner.js:49: setVisibilityDomElement:
null,
On 2014/09/10 19:13:37, Dan Beam wrote:
> nit: visibilityDomElement (prefixing with "set" definitely sounds like this is
> an accessor)

Done, renamed 4 occurrences.

[engedy, 2014-09-11 11:51:25]

engedy@chromium.org changed reviewers:
- battre@chromium.org

[engedy, 2014-09-11 15:03:54]

The CQ bit was checked by engedy@chromium.org

[commit-bot: I haz the power, 2014-09-11 15:04:24]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patchset/533183002/100001

[commit-bot: I haz the power, 2014-09-11 15:16:24]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-09-11 15:16:26]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[engedy, 2014-09-11 15:21:49]

The CQ bit was checked by engedy@chromium.org

[commit-bot: I haz the power, 2014-09-11 15:22:08]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patchset/533183002/100001

[commit-bot: I haz the power, 2014-09-11 15:29:49]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-09-11 15:29:51]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[engedy, 2014-09-11 15:43:52]

The CQ bit was checked by engedy@chromium.org

[commit-bot: I haz the power, 2014-09-11 15:45:36]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patchset/533183002/100001

[commit-bot: I haz the power, 2014-09-11 16:03:13]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-09-11 16:03:14]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[engedy, 2014-09-18 08:44:21]

The CQ bit was checked by engedy@chromium.org

[commit-bot: I haz the power, 2014-09-18 08:45:12]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patchset/533183002/120001

[commit-bot: I haz the power, 2014-09-18 09:22:15]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-09-18 09:22:17]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[engedy, 2014-09-18 10:43:35]

Committed patchset #8 (id:140001) manually as 9d0221c (presubmit successful).

[commit-bot: I haz the power, 2014-09-18 10:56:30]

Patchset 8 (id:??) landed as
https://crrev.com/9d0221cd251502231877f943fa2872a2f92a5621
Cr-Commit-Position: refs/heads/master@{#295450}