Introduce ServiceWorker.ActivatedWorkerPreparationForMainFrame.Time UMA.

Introduce ServiceWorker.ActivatedWorkerPreparationForMainFrame.Time UMA.

We can measure the effect of the speculatively launch of Service Workers on UI-events by this metric.

BUG=616502
Committed: https://crrev.com/dc54e7bda1c339def75e712235e166ab575d41b7
Cr-Commit-Position: refs/heads/master@{#398814}

[horo, 2016-06-06 10:53:55]

horo@chromium.org changed reviewers:
+ falken@chromium.org

[horo, 2016-06-06 10:53:56]

falken@
Could you please review this?

[horo, 2016-06-06 11:12:22]

Description was changed from

==========
Introduce ServiceWorker.ActivatedWorkerPreparationForMainFrame.Time UMA.

BUG=616502
==========

to

==========
Introduce ServiceWorker.ActivatedWorkerPreparationForMainFrame.Time UMA.

We can measure the effect of the speculatively launch of Service Workers on
UI-events by this metric.

BUG=616502
==========

[falken, 2016-06-07 03:46:12]

https://codereview.chromium.org/2039743003/diff/40001/content/browser/service...
File content/browser/service_worker/embedded_worker_instance.h (right):

https://codereview.chromium.org/2039743003/diff/40001/content/browser/service...
content/browser/service_worker/embedded_worker_instance.h:55: typedef
EmbeddedWorkerStatus Status;
I think it's now:
using EmbeddedWorkerStatus = Status

But I tend to prefer to just write out EmbeddedWorkerStatus to eliminate the
level of indirection.

https://codereview.chromium.org/2039743003/diff/40001/content/browser/service...
content/browser/service_worker/embedded_worker_instance.h:162:
ServiceWorkerMetrics::StartSituation start_situation() const {
Does it make sense to have DCHECK(STARTING || RUNNING) here?

https://codereview.chromium.org/2039743003/diff/40001/content/browser/service...
content/browser/service_worker/embedded_worker_instance.h:314:
ServiceWorkerMetrics::StartSituation::UNKNOWN;
It's a little unfortunate this state has to move out of StartTask. Can you add
comments about when this member is valid?

https://codereview.chromium.org/2039743003/diff/40001/content/browser/service...
File content/browser/service_worker/service_worker_context_core.cc (right):

https://codereview.chromium.org/2039743003/diff/40001/content/browser/service...
content/browser/service_worker/service_worker_context_core.cc:121:
ServiceWorkerVersion::RunningStatus::RUNNING) {
Should we use EmbeddedWorkerStatus:: for these uses now?

https://codereview.chromium.org/2039743003/diff/40001/content/browser/service...
File content/browser/service_worker/service_worker_url_request_job.cc (right):

https://codereview.chromium.org/2039743003/diff/40001/content/browser/service...
content/browser/service_worker/service_worker_url_request_job.cc:646:
worker_ready_time_ - request()->creation_time(), initial_worker_status_,
When is request()->creation_time() set?

I'm wondering how much this is measuring. Does it include time spent in the
renderer?

https://codereview.chromium.org/2039743003/diff/40001/content/browser/service...
File content/browser/service_worker/service_worker_version.h (right):

https://codereview.chromium.org/2039743003/diff/40001/content/browser/service...
content/browser/service_worker/service_worker_version.h:70: typedef
EmbeddedWorkerStatus RunningStatus;
I'm not sure this typedef is an improvement. Can we just use
EmbeddedWorkerStatus everywhere?

https://codereview.chromium.org/2039743003/diff/40001/tools/metrics/histogram...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/2039743003/diff/40001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:49528: +    The time taken to prepare an
activated Service Worker for a main frame
I think "prepare" is ambiguous. It could sound like the time taken to find a
registration and wait for a waiting worker to become activated. Could this
explanation:
- Explain exactly when the measurement starts and ends?
- Explain that it's not recorded unless the worker was already activated?

https://codereview.chromium.org/2039743003/diff/40001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:49530: +    fetch and DevTools was ever
attached to the Service Worker during startup.
"not recorded if the SW was started for the fetch" should be "not recorded if
the SW was already started" ?

https://codereview.chromium.org/2039743003/diff/40001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:97000: +  <suffix name="SartingWorker"
label="SartingWorker"/>
s/Sarting/Starting/g

[horo, 2016-06-07 05:58:12]

https://codereview.chromium.org/2039743003/diff/40001/content/browser/service...
File content/browser/service_worker/embedded_worker_instance.h (right):

https://codereview.chromium.org/2039743003/diff/40001/content/browser/service...
content/browser/service_worker/embedded_worker_instance.h:55: typedef
EmbeddedWorkerStatus Status;
On 2016/06/07 03:46:12, falken wrote:
> I think it's now:
> using EmbeddedWorkerStatus = Status
> 
> But I tend to prefer to just write out EmbeddedWorkerStatus to eliminate the
> level of indirection.

Done.

https://codereview.chromium.org/2039743003/diff/40001/content/browser/service...
content/browser/service_worker/embedded_worker_instance.h:162:
ServiceWorkerMetrics::StartSituation start_situation() const {
On 2016/06/07 03:46:12, falken wrote:
> Does it make sense to have DCHECK(STARTING || RUNNING) here?

Done.

https://codereview.chromium.org/2039743003/diff/40001/content/browser/service...
content/browser/service_worker/embedded_worker_instance.h:314:
ServiceWorkerMetrics::StartSituation::UNKNOWN;
On 2016/06/07 03:46:12, falken wrote:
> It's a little unfortunate this state has to move out of StartTask. Can you add
> comments about when this member is valid?

Done.

https://codereview.chromium.org/2039743003/diff/40001/content/browser/service...
File content/browser/service_worker/service_worker_url_request_job.cc (right):

https://codereview.chromium.org/2039743003/diff/40001/content/browser/service...
content/browser/service_worker/service_worker_url_request_job.cc:646:
worker_ready_time_ - request()->creation_time(), initial_worker_status_,
On 2016/06/07 03:46:12, falken wrote:
> When is request()->creation_time() set?
> 
> I'm wondering how much this is measuring. Does it include time spent in the
> renderer?

This is set when net::URLRequest is created in
ResourceDispatcherHostImpl::BeginRequest().
It doesn't include the time spent in the renderer.

https://codereview.chromium.org/2039743003/diff/40001/content/browser/service...
File content/browser/service_worker/service_worker_version.h (right):

https://codereview.chromium.org/2039743003/diff/40001/content/browser/service...
content/browser/service_worker/service_worker_version.h:70: typedef
EmbeddedWorkerStatus RunningStatus;
On 2016/06/07 03:46:12, falken wrote:
> I'm not sure this typedef is an improvement. Can we just use
> EmbeddedWorkerStatus everywhere?

Done.

https://codereview.chromium.org/2039743003/diff/40001/tools/metrics/histogram...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/2039743003/diff/40001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:49528: +    The time taken to prepare an
activated Service Worker for a main frame
On 2016/06/07 03:46:12, falken wrote:
> I think "prepare" is ambiguous. It could sound like the time taken to find a
> registration and wait for a waiting worker to become activated. Could this
> explanation:
> - Explain exactly when the measurement starts and ends?
> - Explain that it's not recorded unless the worker was already activated?

Done.

https://codereview.chromium.org/2039743003/diff/40001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:49530: +    fetch and DevTools was ever
attached to the Service Worker during startup.
On 2016/06/07 03:46:12, falken wrote:
> "not recorded if the SW was started for the fetch" should be "not recorded if
> the SW was already started" ?

No.
When the SW was already started, it is recorded as
ServiceWorker.ActivatedWorkerPreparationForMainFrame.Time_RunningWorker.

https://codereview.chromium.org/2039743003/diff/40001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:97000: +  <suffix name="SartingWorker"
label="SartingWorker"/>
On 2016/06/07 03:46:12, falken wrote:
> s/Sarting/Starting/g

Done.

[falken, 2016-06-07 06:20:30]

https://codereview.chromium.org/2039743003/diff/60001/content/browser/service...
File content/browser/service_worker/embedded_worker_instance.cc (right):

https://codereview.chromium.org/2039743003/diff/60001/content/browser/service...
content/browser/service_worker/embedded_worker_instance.cc:846: NOTREACHED();
curious: why remove the status output?

https://codereview.chromium.org/2039743003/diff/60001/content/browser/service...
File content/browser/service_worker/service_worker_url_request_job.cc (right):

https://codereview.chromium.org/2039743003/diff/60001/content/browser/service...
content/browser/service_worker/service_worker_url_request_job.cc:637: const
scoped_refptr<ServiceWorkerVersion>& version) {
const scoped_refptr& is deprecated. Now we use scoped_refptr with std::move if
appropriate.

http://www.chromium.org/developers/smart-pointer-guidelines#TOC-What-about-pa...

https://codereview.chromium.org/2039743003/diff/60001/content/browser/service...
content/browser/service_worker/service_worker_url_request_job.cc:642:
initial_worker_status_ != EmbeddedWorkerStatus::RUNNING) &&
Doesn't that mean
ServiceWorker.ActivatedWorkerPreparationForMainFrame.Time_RunningWorker is never
recorded?

https://codereview.chromium.org/2039743003/diff/60001/tools/metrics/histogram...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/2039743003/diff/60001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:49567: +    worker was started for the
fetch and DevTools was ever attached to the
Sorry I don't understand what "is not recorded if the worker was started for the
fetch" means, given
ServiceWorker.ActivatedWorkerPreparationForMainFrame.Time_RunningWorker is
intended to be recorded.

[horo, 2016-06-07 06:58:48]

https://codereview.chromium.org/2039743003/diff/60001/content/browser/service...
File content/browser/service_worker/embedded_worker_instance.cc (right):

https://codereview.chromium.org/2039743003/diff/60001/content/browser/service...
content/browser/service_worker/embedded_worker_instance.cc:846: NOTREACHED();
On 2016/06/07 06:20:30, falken wrote:
> curious: why remove the status output?

Done.

https://codereview.chromium.org/2039743003/diff/60001/content/browser/service...
File content/browser/service_worker/service_worker_url_request_job.cc (right):

https://codereview.chromium.org/2039743003/diff/60001/content/browser/service...
content/browser/service_worker/service_worker_url_request_job.cc:637: const
scoped_refptr<ServiceWorkerVersion>& version) {
On 2016/06/07 06:20:30, falken wrote:
> const scoped_refptr& is deprecated. Now we use scoped_refptr with std::move if
> appropriate.
> 
>
http://www.chromium.org/developers/smart-pointer-guidelines#TOC-What-about-pa...

Done.

https://codereview.chromium.org/2039743003/diff/60001/content/browser/service...
content/browser/service_worker/service_worker_url_request_job.cc:642:
initial_worker_status_ != EmbeddedWorkerStatus::RUNNING) &&
On 2016/06/07 06:20:30, falken wrote:
> Doesn't that mean
> ServiceWorker.ActivatedWorkerPreparationForMainFrame.Time_RunningWorker is
never
> recorded?

"!(version->skip_recording_startup_time() &&
   initial_worker_status_ != EmbeddedWorkerStatus::RUNNING)" means:

If the DevTools was attached and the worker is started for this URL request, we
don't record the metric.

https://codereview.chromium.org/2039743003/diff/60001/tools/metrics/histogram...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/2039743003/diff/60001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:49567: +    worker was started for the
fetch and DevTools was ever attached to the
On 2016/06/07 06:20:30, falken wrote:
> Sorry I don't understand what "is not recorded if the worker was started for
the
> fetch" means, given
> ServiceWorker.ActivatedWorkerPreparationForMainFrame.Time_RunningWorker is
> intended to be recorded.

Updated the summary.

[falken, 2016-06-07 07:33:48]

lgtm, thanks

https://codereview.chromium.org/2039743003/diff/80001/content/browser/service...
File content/browser/service_worker/service_worker_url_request_job.cc (right):

https://codereview.chromium.org/2039743003/diff/80001/content/browser/service...
content/browser/service_worker/service_worker_url_request_job.cc:643:
!ServiceWorkerMetrics::ShouldExcludeURLFromHistogram(request()->url())) {
OK I finally understand this. I wonder if this is easier to read as an early
return:

if (resource_type != RESOURCE_TYPE_MAIN_FRAME || !worker_already_activated
|| (version->skip_recording_startup_time() && initial_worker_status_ !=
EmbeddedWorkerStatus::RUNNING)
|| ServiceWorkerMetrics::ShouldExcludeURLFromHistogram(request()->url())
  return;

(or even split into multiple ifs)

This may be easier to grok than the current (p && q && !(r && t != u) && !v)
form.

https://codereview.chromium.org/2039743003/diff/80001/tools/metrics/histogram...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/2039743003/diff/80001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:49562: +    started to send a FetchEvent
request for a main frame HTML file. The
"HTML file" -> "resource" may be more usual wording.

https://codereview.chromium.org/2039743003/diff/80001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:97083: +  <suffix name="StoppingWorker"
label="StoppingWorker"/>
Consider making these labels more description: they're appended to the
description of the affected histogram.

Suggestions:
"StartingWorker means the activated worker was already starting up."
"RunningWorker means the activated worker was already running."
"StoppingWorker means the activated worker was stopping."

[horo, 2016-06-07 07:54:59]

https://codereview.chromium.org/2039743003/diff/80001/content/browser/service...
File content/browser/service_worker/service_worker_url_request_job.cc (right):

https://codereview.chromium.org/2039743003/diff/80001/content/browser/service...
content/browser/service_worker/service_worker_url_request_job.cc:643:
!ServiceWorkerMetrics::ShouldExcludeURLFromHistogram(request()->url())) {
On 2016/06/07 07:33:48, falken wrote:
> OK I finally understand this. I wonder if this is easier to read as an early
> return:
> 
> if (resource_type != RESOURCE_TYPE_MAIN_FRAME || !worker_already_activated
> || (version->skip_recording_startup_time() && initial_worker_status_ !=
> EmbeddedWorkerStatus::RUNNING)
> || ServiceWorkerMetrics::ShouldExcludeURLFromHistogram(request()->url())
>   return;
> 
> (or even split into multiple ifs)
> 
> This may be easier to grok than the current (p && q && !(r && t != u) && !v)
> form.

Added comments.
Done.

https://codereview.chromium.org/2039743003/diff/80001/tools/metrics/histogram...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/2039743003/diff/80001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:49562: +    started to send a FetchEvent
request for a main frame HTML file. The
On 2016/06/07 07:33:48, falken wrote:
> "HTML file" -> "resource" may be more usual wording.

Done.

https://codereview.chromium.org/2039743003/diff/80001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:97083: +  <suffix name="StoppingWorker"
label="StoppingWorker"/>
On 2016/06/07 07:33:48, falken wrote:
> Consider making these labels more description: they're appended to the
> description of the affected histogram.
> 
> Suggestions:
> "StartingWorker means the activated worker was already starting up."
> "RunningWorker means the activated worker was already running."
> "StoppingWorker means the activated worker was stopping."

Done.

[horo, 2016-06-07 07:58:05]

horo@chromium.org changed reviewers:
+ jkarlin@chromium.org, mpearson@chromium.org, yurys@chromium.org

[horo, 2016-06-07 07:58:07]

jkarlin@
Please review content/browser/background_sync/background_sync_manager.cc.

yurys@
Please review content/browser/devtools/protocol/service_worker_handler.cc.

mpearson@
Please review histograms.xml.

[jkarlin, 2016-06-07 10:49:50]

background_sync/ lgtm

[yurys, 2016-06-07 16:46:47]

yurys@chromium.org changed reviewers:
+ dgozman@chromium.org
- yurys@chromium.org

[Mark P, 2016-06-07 17:44:10]

Afraid to say it, but you histograms.xml needs a lot of clarification.

https://codereview.chromium.org/2039743003/diff/100001/tools/metrics/histogra...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/2039743003/diff/100001/tools/metrics/histogra...
tools/metrics/histograms/histograms.xml:49562: +    started to send a FetchEvent
request for a main frame resource. The
(1)
I'm having trouble parsing this (first) sentence.  Should the word "started" be
removed?
(2)
I don't understand the second sentence in combination with the first.  The first
implies that the terminating event is "send a FetchEvent request".  The second
implies the terminating event is "finds a running worker or successfully starts
a worker."  These sound like different things to me.
(3)
receives is spelled as such
(4)
The third sentence "not recorded ... if the worker was not activated yet" is
confusing given the first two sentences.  I think this limitation should be
expressed more clearly in the first/second sentence, perhaps by saying something
like "find an active worker" up there, and in a following sentence saying that
If no worker is active, then this metric is not recorded.  (The registration and
sending the request will still take place.  The timing will not be emitted to
this histogram however.)
(5)
You can still have the devtools and New Tab Page restrictions at the end of the
description.  It would be nice to briefly justify the New Tab Page restriction,
just as you do the devtools restriction.

https://codereview.chromium.org/2039743003/diff/100001/tools/metrics/histogra...
tools/metrics/histograms/histograms.xml:97079: +      label="Started a worker
during browser startup."/>
I find these labels confusing, mainly because I thought the histogram was only
emitted for workers that were already activated.  Yet, by implication, only
three of these labels have already-active workers; two do not.  Why are those
emitted to the histogram?

[horo, 2016-06-08 04:13:23]

https://codereview.chromium.org/2039743003/diff/100001/tools/metrics/histogra...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/2039743003/diff/100001/tools/metrics/histogra...
tools/metrics/histograms/histograms.xml:49562: +    started to send a FetchEvent
request for a main frame resource. The
On 2016/06/07 17:44:09, Mark P wrote:
> (1)
> I'm having trouble parsing this (first) sentence.  Should the word "started"
be
> removed?
> (2)
> I don't understand the second sentence in combination with the first.  The
first
> implies that the terminating event is "send a FetchEvent request".  The second
> implies the terminating event is "finds a running worker or successfully
starts
> a worker."  These sound like different things to me.
> (3)
> receives is spelled as such
> (4)
> The third sentence "not recorded ... if the worker was not activated yet" is
> confusing given the first two sentences.  I think this limitation should be
> expressed more clearly in the first/second sentence, perhaps by saying
something
> like "find an active worker" up there, and in a following sentence saying that
> If no worker is active, then this metric is not recorded.  (The registration
and
> sending the request will still take place.  The timing will not be emitted to
> this histogram however.)
> (5)
> You can still have the devtools and New Tab Page restrictions at the end of
the
> description.  It would be nice to briefly justify the New Tab Page
restriction,
> just as you do the devtools restriction.

Done.
Revised the summary.

https://codereview.chromium.org/2039743003/diff/100001/tools/metrics/histogra...
tools/metrics/histograms/histograms.xml:97079: +      label="Started a worker
during browser startup."/>
On 2016/06/07 17:44:09, Mark P wrote:
> I find these labels confusing, mainly because I thought the histogram was only
> emitted for workers that were already activated.  Yet, by implication, only
> three of these labels have already-active workers; two do not.  Why are those
> emitted to the histogram?

An "ACTIVE" Service Worker is different from a started Service Worker.
ACTIVE is a technical term in Service Worker spec.
>
https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#service-work...
> A service worker registration has an associated installing worker (a service
worker or null) whose state is installing. It is initially set to null.
> A service worker registration has an associated waiting worker (a service
worker or null) whose state is installed. It is initially set to null.
> A service worker registration has an associated active worker (a service
worker or null) whose state is either activating or activated. It is initially
set to null.

There could be an ACTIVE stopped worker, and also a running worker which is not
activated.

[Mark P, 2016-06-08 20:08:46]

thank you for the extensive revisions.  histograms.xml lgtm, baring some minor
comments below

--mark

https://codereview.chromium.org/2039743003/diff/120001/tools/metrics/histogra...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/2039743003/diff/120001/tools/metrics/histogra...
tools/metrics/histograms/histograms.xml:49562: +    to which to dispatch a
FetchEvent for a main frame resource request. For
delete "to which"

https://codereview.chromium.org/2039743003/diff/120001/tools/metrics/histogra...
tools/metrics/histograms/histograms.xml:49570: +    successfully started. The
metric is not recorded in the following
after "started", perhaps add "(we do not include in the time it takes for the
worker to become ACTIVATED)" (if true)

[horo, 2016-06-08 22:54:51]

Thank you!

https://codereview.chromium.org/2039743003/diff/120001/tools/metrics/histogra...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/2039743003/diff/120001/tools/metrics/histogra...
tools/metrics/histograms/histograms.xml:49562: +    to which to dispatch a
FetchEvent for a main frame resource request. For
On 2016/06/08 20:08:46, Mark P wrote:
> delete "to which"

Done.

https://codereview.chromium.org/2039743003/diff/120001/tools/metrics/histogra...
tools/metrics/histograms/histograms.xml:49570: +    successfully started. The
metric is not recorded in the following
On 2016/06/08 20:08:45, Mark P wrote:
> after "started", perhaps add "(we do not include in the time it takes for the
> worker to become ACTIVATED)" (if true)

Done.

[horo, 2016-06-08 22:54:59]

The CQ bit was checked by horo@chromium.org

[horo, 2016-06-08 22:55:00]

The patchset sent to the CQ was uploaded after l-g-t-m from falken@chromium.org,
jkarlin@chromium.org, mpearson@chromium.org
Link to the patchset: https://codereview.chromium.org/2039743003/#ps140001
(title: " ")

[commit-bot: I haz the power, 2016-06-08 22:55:38]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2039743003/140001

[commit-bot: I haz the power, 2016-06-08 23:04:38]

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

[commit-bot: I haz the power, 2016-06-08 23:04:40]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[horo, 2016-06-09 05:49:47]

dgozman@
Could you please reivew
content/browser/devtools/protocol/service_worker_handler.cc?

[pfeldman, 2016-06-09 06:00:01]

pfeldman@chromium.org changed reviewers:
+ pfeldman@chromium.org

[pfeldman, 2016-06-09 06:00:02]

devtools lgtm

[horo, 2016-06-09 06:06:04]

Thank you

[horo, 2016-06-09 06:39:37]

The CQ bit was checked by horo@chromium.org

[commit-bot: I haz the power, 2016-06-09 06:39:53]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2039743003/140001

[commit-bot: I haz the power, 2016-06-09 08:16:58]

Description was changed from

==========
Introduce ServiceWorker.ActivatedWorkerPreparationForMainFrame.Time UMA.

We can measure the effect of the speculatively launch of Service Workers on
UI-events by this metric.

BUG=616502
==========

to

==========
Introduce ServiceWorker.ActivatedWorkerPreparationForMainFrame.Time UMA.

We can measure the effect of the speculatively launch of Service Workers on
UI-events by this metric.

BUG=616502
==========

[commit-bot: I haz the power, 2016-06-09 08:16:59]

Committed patchset #8 (id:140001)

[commit-bot: I haz the power, 2016-06-09 08:18:24]

Description was changed from

==========
Introduce ServiceWorker.ActivatedWorkerPreparationForMainFrame.Time UMA.

We can measure the effect of the speculatively launch of Service Workers on
UI-events by this metric.

BUG=616502
==========

to

==========
Introduce ServiceWorker.ActivatedWorkerPreparationForMainFrame.Time UMA.

We can measure the effect of the speculatively launch of Service Workers on
UI-events by this metric.

BUG=616502

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

[commit-bot: I haz the power, 2016-06-09 08:18:27]

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