It turns out that when we implemented process uptimes, we only did it for the renderer, not browser/gpu process. Oops!

I think we should do roughly the following:

1) When the coordination unit is created for any process, record the current time. Equate this with the "launch time" of the process, even though it will be very slightly off.
2) When a navigation occurs, we record the navigation time of the appropriate GRC property on the WebContentsCU. 

When we emit metrics, we grab:
3) Current time - launch time = process launch time. 
4) For ProcessCUs that have exactly 1 WebCU, we grab the time since last navigation on that WebCU and subtract the launch time.

1) When the coordination unit is created for any process, record the current time.

We only create coordination unit for render processes, but we do have a plan to create coordination unit for gpu process, and maybe browser process in the future.

> 2) When a navigation occurs, we record the navigation time of the appropriate GRC property on the WebContentsCU. 

I have a question, do you only want to record the navigation time of the main frame?

1) When the coordination unit is created for any process, record the current time.

We only create coordination unit for render processes, but we do have a plan to create coordination unit for gpu process, and maybe browser process in the future.

> 2) When a navigation occurs, we record the navigation time of the appropriate GRC property on the WebContentsCU. 

I have a question, do you only want to record the navigation time of the main frame?

> We only create coordination unit for render processes, but we do have a plan to create coordination unit for gpu process, and maybe browser process in the future.

Any reason we can't add that now? Seems pretty straight forward, and would solve htis problem.

> I have a question, do you only want to record the navigation time of the main frame?
We actually care less about "mainness" of a frame, but rather about whether or not a renderer is hosting a single frame - since that's the only case where our metrics make sense.

> Any reason we can't add that now? Seems pretty straight forward, and would solve htis problem.

oh I am not saying we can't add that, we can definitely add it with use case.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/451e96e37d9398a600f232cd6830fa3013f2d7a5

commit 451e96e37d9398a600f232cd6830fa3013f2d7a5
Author: Fadi Meawad <fmeawad@chromium.org>
Date: Wed Oct 11 19:27:56 2017

[Memory UKM] Add IsVisible, TimeSinceLastVisibilityChange and TimeSinceLastNavigation to the Memory UKM Record

This CL does the follow:
* It removes the local PageData from the MetricsCollector
  (including last_invisible_time and navigation_finished_time)
* Adds the new fields to PageCoordinationUnitImpl
* Merges the new fields with UkmSourceId into a new PageInfo
  mojo struct in CoordinationUnitIntrospectorImpl
* Add the new values to ProcessMemoryMetricsEmitter to be included
  as part of the UKM record.
* cleanup: Remove kURL from singals.mojom since it is no longer used.

Bug:  chromium:764098 , chromium:757873 
Change-Id: I53cc6e85fc991cf27c8dc45fb6b38a67c0901a19
Reviewed-on: https://chromium-review.googlesource.com/666295
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: oysteine <oysteine@chromium.org>
Reviewed-by: Erik Chen <erikchen@chromium.org>
Reviewed-by: lpy <lpy@chromium.org>
Reviewed-by: Steven Holte <holte@chromium.org>
Commit-Queue: Fadi Meawad <fmeawad@chromium.org>
Cr-Commit-Position: refs/heads/master@{#508065}
[modify] https://crrev.com/451e96e37d9398a600f232cd6830fa3013f2d7a5/chrome/browser/metrics/process_memory_metrics_emitter.cc
[modify] https://crrev.com/451e96e37d9398a600f232cd6830fa3013f2d7a5/chrome/browser/metrics/process_memory_metrics_emitter_browsertest.cc
[modify] https://crrev.com/451e96e37d9398a600f232cd6830fa3013f2d7a5/chrome/browser/metrics/process_memory_metrics_emitter_unittest.cc
[modify] https://crrev.com/451e96e37d9398a600f232cd6830fa3013f2d7a5/services/resource_coordinator/coordination_unit/coordination_unit_introspector_impl.cc
[modify] https://crrev.com/451e96e37d9398a600f232cd6830fa3013f2d7a5/services/resource_coordinator/coordination_unit/page_coordination_unit_impl.cc
[modify] https://crrev.com/451e96e37d9398a600f232cd6830fa3013f2d7a5/services/resource_coordinator/coordination_unit/page_coordination_unit_impl.h
[modify] https://crrev.com/451e96e37d9398a600f232cd6830fa3013f2d7a5/services/resource_coordinator/coordination_unit/page_coordination_unit_impl_unittest.cc
[modify] https://crrev.com/451e96e37d9398a600f232cd6830fa3013f2d7a5/services/resource_coordinator/observers/metrics_collector.cc
[modify] https://crrev.com/451e96e37d9398a600f232cd6830fa3013f2d7a5/services/resource_coordinator/observers/metrics_collector.h
[modify] https://crrev.com/451e96e37d9398a600f232cd6830fa3013f2d7a5/services/resource_coordinator/observers/metrics_collector_unittest.cc
[modify] https://crrev.com/451e96e37d9398a600f232cd6830fa3013f2d7a5/services/resource_coordinator/public/interfaces/coordination_unit_introspector.mojom
[modify] https://crrev.com/451e96e37d9398a600f232cd6830fa3013f2d7a5/services/resource_coordinator/public/interfaces/signals.mojom
[modify] https://crrev.com/451e96e37d9398a600f232cd6830fa3013f2d7a5/tools/metrics/ukm/ukm.xml