Implement a poor man's PostAfterStartupTask() function.

chrome/browser/chrome_browser_main.cc

Index: chrome/browser/chrome_browser_main.cc
diff --git a/chrome/browser/chrome_browser_main.cc b/chrome/browser/chrome_browser_main.cc
index 5c7cbfc51bfed0b30ef5ba880e05deac750f8b38..0c5e5ae14be47994bd0200ba17537e11f264f3e3 100644
--- a/chrome/browser/chrome_browser_main.cc
+++ b/chrome/browser/chrome_browser_main.cc
@@ -31,6 +31,7 @@
 #include "base/strings/string_split.h"
 #include "base/strings/sys_string_conversions.h"
 #include "base/strings/utf_string_conversions.h"
+#include "base/synchronization/cancellation_flag.h"
 #include "base/sys_info.h"
 #include "base/threading/platform_thread.h"
 #include "base/time/time.h"
@@ -222,6 +223,25 @@
 
 using content::BrowserThread;
 
+
+
+namespace {
+using StartupCompleteFlag = base::CancellationFlag;

[gab, 2015/03/10 15:00:32]

Feels weird to use "CancellationFlag" here although it does exactly what we
need...

I guess the next closest thing would be a WaitableEvent(true, false); which
would be slightly more heavy weight.

Perhaps CancellationFlag should be repurposed to be non-"Cancellation" specific
(not in this CL, but just a thought for the Chrome owners to weigh).

[michaeln, 2015/03/10 19:46:26]

^^^ this

[gab, 2015/03/10 19:55:27]

One simple way to do this would be to rename the class, but add a

using CancellationFlag = NewFlagClassName;

at the top of the header to avoid having to rename every user just yet if ever.

+base::LazyInstance<StartupCompleteFlag>::Leaky g_startup_complete_flag;
+}
+
+namespace chrome {
+
+bool IsBrowserStartupComplete() {
+  return g_startup_complete_flag.Get().IsSet();
+}
+
+void SetBrowserStartupIsComplete() {
+  g_startup_complete_flag.Get().Set();
+}
+
+}
+
 namespace {
 
 // This function provides some ways to test crash and assertion handling
@@ -588,6 +608,8 @@ ChromeBrowserMainParts::ChromeBrowserMainParts(
   // cookies need to go through one of Chrome's URLRequestContexts which have
   // a ChromeNetworkDelegate attached that selectively allows cookies again.
   net::URLRequest::SetDefaultCookiePolicyToBlock();
+
+  g_startup_complete_flag.Get();
 }
 
 ChromeBrowserMainParts::~ChromeBrowserMainParts() {
@@ -1109,6 +1131,13 @@ void ChromeBrowserMainParts::PostBrowserStart() {
       base::Bind(&WebRtcLogUtil::DeleteOldWebRtcLogFilesForAllProfiles),

[michaeln, 2015/03/10 19:46:26]

This might be a good candidate for PostAfterStartupTask().

       base::TimeDelta::FromMinutes(1));
 #endif  // defined(ENABLE_WEBRTC)
+
+  // Failsafe for signaling startup completion.

[jam, 2015/03/10 23:04:34]

why do we need a failsafe?

under what circumstance would a page load never happen and we want these delayed
tasks to run?

[michaeln, 2015/03/10 23:54:54]

The first page is closed prior to getting to the loaded state.

Chrome is being started headless just to run ServiceWorkers for sync'ing
purposes so no page is loaded.

I may be thinking ahead toward hooking this into session restore too much, but
the notion of when the browser is started up is not well defined, the sum of
some set of signals == started up. I want to make it easy/safe to experiment
with exactly what constitutes 'started up' and I'm wary of corner cases that
might prevent a signal.

+  BrowserThread::PostDelayedTask(
+      BrowserThread::UI,
+      FROM_HERE,
+      base::Bind(&chrome::SetBrowserStartupIsComplete),
+      base::TimeDelta::FromMinutes(3));

[gab, 2015/03/10 15:00:32]

Is PostBrowserStart() called in background mode launches (i.e. before an
explicit Chrome launch)? I would guess not.

I assume PostMainMessageLoopStart() would be called though even if in background
mode, this would thus be a better place for this code IMO.

[michaeln, 2015/03/10 19:46:26]

I'm really not sure about which of these methods gets called when and on which
platforms? The NOTREACHED in PostMainMessageLoopStart tells me its not used on
android. Any guidance i can get about where to best place the failsafe and where
to signal 'complete' would be great.

Maybe the failsafe timer should start earlier in the startup process, as soon as
BrowserThread::PostDelayedTask(UI...) can be called?

[gab, 2015/03/10 19:55:27]

Makes sense to post it in a safe and early spot IMO since it's a long timer
anyways.

 }
 
 int ChromeBrowserMainParts::PreMainMessageLoopRunImpl() {