Fix flaky test ContentVerifierPolicyTest.PolicyCorruptedOnStartup

Fix flaky test ContentVerifierPolicyTest.PolicyCorruptedOnStartup

The way this test works is that the PRE_ test disables a policy force
installed extension due to corruption, and then the regular test checks
that it gets properly reinstalled after startup. It turns out that the
reinstall gets scheduled pretty early on during startup - in
ExtensionService::CheckForExternalUpdates which happens after
SetUpInProcessBrowserTestFixture, and on the build waterfall that
sometimes completes before SetUpOnMainThread of the tesst runs, let
alone when the regular test body runs. On a local development machine I
wasn't able to reproduce this unless I induced a lot of extra load using
stress-ng.

So the fix is to switch the test from assuming the install will happen
during the regular test body to first checking whether it already
happened before the start of the test, and only waiting for it if it
hadn't already happened.

BUG=668067
Committed: https://crrev.com/ba52f3250a997eaee8663d6731819431bca18a71
Cr-Commit-Position: refs/heads/master@{#435344}

[asargent_no_longer_on_chrome, 2016-11-28 23:09:34]

The CQ bit was checked by asargent@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-28 23:10:36]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-29 01:34:22]

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

[commit-bot: I haz the power, 2016-11-29 01:34:23]

Dry run: This issue passed the CQ dry run.

[asargent_no_longer_on_chrome, 2016-11-29 18:41:18]

asargent@chromium.org changed reviewers:
+ rdevlin.cronin@chromium.org

[Devlin, 2016-11-29 22:46:38]

https://codereview.chromium.org/2537623002/diff/1/chrome/browser/extensions/c...
File chrome/browser/extensions/content_verifier_browsertest.cc (right):

https://codereview.chromium.org/2537623002/diff/1/chrome/browser/extensions/c...
chrome/browser/extensions/content_verifier_browsertest.cc:747: reasons =
prefs->GetDisableReasons(id_);
Could we end the test with checking the disable reasons in all cases, and maybe
checking that it's in the enabled_extensions set?  i.e., moving this line and
the one below outside the if and adding another check for the registry.

[asargent_no_longer_on_chrome, 2016-11-30 01:02:05]

https://codereview.chromium.org/2537623002/diff/1/chrome/browser/extensions/c...
File chrome/browser/extensions/content_verifier_browsertest.cc (right):

https://codereview.chromium.org/2537623002/diff/1/chrome/browser/extensions/c...
chrome/browser/extensions/content_verifier_browsertest.cc:747: reasons =
prefs->GetDisableReasons(id_);
On 2016/11/29 22:46:38, Devlin wrote:
> Could we end the test with checking the disable reasons in all cases, and
maybe
> checking that it's in the enabled_extensions set?  i.e., moving this line and
> the one below outside the if and adding another check for the registry.

Good suggestion - done.

[asargent_no_longer_on_chrome, 2016-11-30 01:02:08]

The CQ bit was checked by asargent@chromium.org

[commit-bot: I haz the power, 2016-11-30 01:04:25]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-30 01:04:26]

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

[commit-bot: I haz the power, 2016-11-30 01:04:26]

No L-G-T-M from a valid reviewer yet. 
CQ run can only be started by full committers or once the patch has
received an L-G-T-M from a full committer.
Even if an L-G-T-M may have been provided, it was from a non-committer,
_not_ a full super star committer.
See http://www.chromium.org/getting-involved/become-a-committer
Note that this has nothing to do with OWNERS files.

[Devlin, 2016-11-30 01:41:04]

lgtm

[asargent_no_longer_on_chrome, 2016-11-30 17:30:12]

The CQ bit was checked by asargent@chromium.org

[commit-bot: I haz the power, 2016-11-30 17:30:48]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-30 18:26:09]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1480527012499280,
"parent_rev": "9bcfb44df0cdd728fbd54ca84b3242541b5cadb8", "commit_rev":
"1c136da6a2f674ee92d62cff4e120fb62a6aaecf"}

[commit-bot: I haz the power, 2016-11-30 18:26:36]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-11-30 18:31:11]

Description was changed from

==========
Fix flaky test ContentVerifierPolicyTest.PolicyCorruptedOnStartup

The way this test works is that the PRE_ test disables a policy force
installed extension due to corruption, and then the regular test checks
that it gets properly reinstalled after startup. It turns out that the
reinstall gets scheduled pretty early on during startup - in
ExtensionService::CheckForExternalUpdates which happens after
SetUpInProcessBrowserTestFixture, and on the build waterfall that
sometimes completes before SetUpOnMainThread of the tesst runs, let
alone when the regular test body runs. On a local development machine I
wasn't able to reproduce this unless I induced a lot of extra load using
stress-ng.

So the fix is to switch the test from assuming the install will happen
during the regular test body to first checking whether it already
happened before the start of the test, and only waiting for it if it
hadn't already happened.

BUG=668067
==========

to

==========
Fix flaky test ContentVerifierPolicyTest.PolicyCorruptedOnStartup

The way this test works is that the PRE_ test disables a policy force
installed extension due to corruption, and then the regular test checks
that it gets properly reinstalled after startup. It turns out that the
reinstall gets scheduled pretty early on during startup - in
ExtensionService::CheckForExternalUpdates which happens after
SetUpInProcessBrowserTestFixture, and on the build waterfall that
sometimes completes before SetUpOnMainThread of the tesst runs, let
alone when the regular test body runs. On a local development machine I
wasn't able to reproduce this unless I induced a lot of extra load using
stress-ng.

So the fix is to switch the test from assuming the install will happen
during the regular test body to first checking whether it already
happened before the start of the test, and only waiting for it if it
hadn't already happened.

BUG=668067

Committed: https://crrev.com/ba52f3250a997eaee8663d6731819431bca18a71
Cr-Commit-Position: refs/heads/master@{#435344}
==========

[commit-bot: I haz the power, 2016-11-30 18:31:12]

Patchset 2 (id:??) landed as
https://crrev.com/ba52f3250a997eaee8663d6731819431bca18a71
Cr-Commit-Position: refs/heads/master@{#435344}