Write loading signal extra data in JSON

chrome/browser/android/offline_pages/prerendering_loader.cc

Index: chrome/browser/android/offline_pages/prerendering_loader.cc
diff --git a/chrome/browser/android/offline_pages/prerendering_loader.cc b/chrome/browser/android/offline_pages/prerendering_loader.cc
index 680d7bee7e0c57c7ec6c610e82b8b3e7b19134f1..df12f0b883900b2f4a62fcf603be2861973d76e2 100644
--- a/chrome/browser/android/offline_pages/prerendering_loader.cc
+++ b/chrome/browser/android/offline_pages/prerendering_loader.cc
@@ -94,12 +94,10 @@ void PrerenderingLoader::MarkLoadStartTime() {
 }
 
 void PrerenderingLoader::AddLoadingSignal(const char* signal_name) {
-  std::string signal(signal_name);
-  signal += ": ";
   base::TimeTicks current_time = base::TimeTicks::Now();
   base::TimeDelta delay_so_far = current_time - load_start_time_;
-  signal += std::to_string(delay_so_far.InMilliseconds());
-  signal_data_.push_back(signal);
+  double delay = delay_so_far.InMilliseconds();

[romax, 2017/04/18 00:35:09]

TimeDelta::InMillisecondsF returns a double, while the current one is returning
an int64_t. More like a nit but why we're using double over int64_t?

[Pete Williamson, 2017/04/18 18:26:08]

It turns out that double is an acceptable JSON type, but int64_t is not
(JavaScript doesn't know what to do with it.)  The doc in values.h suggests that
we use double if we need an int64_t.  In this case, especially since we are
subtracting off the times to get a delta in milliseconds, we are not in imminent
danger of exceeding the precision offered by a double, and losing any precision.

+  signal_data_.SetDouble(signal_name, delay);
 }
 
 bool PrerenderingLoader::LoadPage(const GURL& url,