Add one-time randomization support for FieldTrial, and the ability to

content/renderer/renderer_main.cc

Index: content/renderer/renderer_main.cc
diff --git a/content/renderer/renderer_main.cc b/content/renderer/renderer_main.cc
index dbb0e34b633aec735d58a0f66ee9f3aced38a2ac..2348ad0c50b8ba7633c845460052fd1c578a9991 100644
--- a/content/renderer/renderer_main.cc
+++ b/content/renderer/renderer_main.cc
@@ -191,8 +191,10 @@ int RendererMain(const MainFunctionParams& parameters) {
     statistics.reset(new base::StatisticsRecorder());
   }
 
-  // Initialize statistical testing infrastructure.
-  base::FieldTrialList field_trial;
+  // Initialize statistical testing infrastructure. We initially set
+  // client_id to be the empty string, but it will be set via the call to
+  // |CreateTrialsInChildProcess()| to whatever it was in our parent process.
+  base::FieldTrialList field_trial(EmptyString());

[jar (doing other things), 2011/05/03 00:17:47]

I'm not sure about this logic now....

The test in line 199 will always return true, as you (now) always pass in the
client_id.  Hence we'll always call for CreateTrialsInChildProcess().  That
suggests you shouldn't bother with the test for the switch.  It also means that
since we *always* call the CreateTrialInChirldProcess(), that we could also do
the construction of the FieldTrialList in that method, and not have to reset the
seed string.  ...which seems cleaner.

...but...

The other alternative is that we should ONLY construct persistent field trials
in the browser process.  This would mean we wouldn't need to pass the seed at
all.  The ONLY reason to create field trials in renderer processes (rather than
a browser process) would be to be able to have different render processes have
different trial values... which would never happen if we had a persistent trial.

Bottom line: Perhaps we should outlaw persistent trials in the renderer process,
and not bother to pass in the seed.  I leaning that way.  This would also
simplify the code a bit.

WDYT?

[Jói, 2011/05/03 17:41:47]

I've outlawed persistent trials in the renderer process.  I started wondering
about this yesterday after I'd done the implementation in StatesToString and
CreateTrialsInChildProcess but decided to leave it in, but I think your comments
show that it really isn't necessary and might even be undesirable to allow
renderer processes to create their own one-time randomized trials.

   // Ensure any field trials in browser are reflected into renderer.
   if (parsed_command_line.HasSwitch(switches::kForceFieldTestNameAndValue)) {
     std::string persistent = parsed_command_line.GetSwitchValueASCII(