LongTaskTiming: add idl, Experiment flag, PerformanceEntry and basic implementation

LongTaskTiming: add idl, Experiment flag, PerformanceEntry and basic implementation

BUG=635596
Committed: https://crrev.com/67ecd9023c61fcf77899dbeca071f5f35aabb8f0
Cr-Commit-Position: refs/heads/master@{#414257}

[panicker, 2016-08-12 21:39:53]

panicker@chromium.org changed reviewers:
+ haraken@chromium.org

[panicker, 2016-08-12 21:39:54]

Hey Kentaro,
may I request a code review for this?
Feel free to suggest alternate reviewer.
See attached bug for more background.
Thanks!

[haraken, 2016-08-13 01:58:36]

On 2016/08/12 21:39:54, Shubhie wrote:
> Hey Kentaro,
> may I request a code review for this?
> Feel free to suggest alternate reviewer.
> See attached bug for more background.
> Thanks!

I'm happy to review the CL from the implementation perspective, but maybe it's
better to ask a person who is more familiar with the feature for review first.
nduca@ or 	igrigorik@?

[panicker, 2016-08-15 16:26:46]

Description was changed from

==========
LongTaskTiming: add idl, Experiment flag, PerformanceEntry and basic
implementation

BUG=635596
==========

to

==========
LongTaskTiming: add idl, Experiment flag, PerformanceEntry and basic
implementation

BUG=635596
==========

[panicker, 2016-08-15 16:26:46]

panicker@chromium.org changed reviewers:
+ nduca@chromium.org

[panicker, 2016-08-15 16:27:35]

On 2016/08/13 01:58:36, haraken wrote:
> On 2016/08/12 21:39:54, Shubhie wrote:
> > Hey Kentaro,
> > may I request a code review for this?
> > Feel free to suggest alternate reviewer.
> > See attached bug for more background.
> > Thanks!
> 
> I'm happy to review the CL from the implementation perspective, but maybe it's
> better to ask a person who is more familiar with the feature for review first.
> nduca@ or 	igrigorik@?

Sure, Nat can sign off on the feature side. Although feature-wise there really
isn't much interesting stuff here yet.

[nduca, 2016-08-16 22:11:22]

lgtm with nit :)

https://codereview.chromium.org/2244813002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/timing/PerformanceBase.cpp (right):

https://codereview.chromium.org/2244813002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/timing/PerformanceBase.cpp:345: void
PerformanceBase::addLongTaskTiming(double startTime, double endTime, String
frameContextUrl)
const String&?

[panicker, 2016-08-16 22:44:38]

Thanks for the review, Nat.
Kentaro - mind taking a look? :)

https://codereview.chromium.org/2244813002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/timing/PerformanceBase.cpp (right):

https://codereview.chromium.org/2244813002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/timing/PerformanceBase.cpp:345: void
PerformanceBase::addLongTaskTiming(double startTime, double endTime, String
frameContextUrl)
On 2016/08/16 22:11:22, nduca wrote:
> const String&?

Done.

[haraken, 2016-08-17 01:15:48]

Mostly looks good.

https://codereview.chromium.org/2244813002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/timing/Performance.idl (right):

https://codereview.chromium.org/2244813002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/timing/Performance.idl:80:
[RuntimeEnabled=LongTaskObserver] void clearLongTaskTimings();

Would it make more sense to rename this to clearLongTaskTimingBuffer? (for
consistency with the following two methods)

https://codereview.chromium.org/2244813002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/timing/PerformanceBase.cpp (right):

https://codereview.chromium.org/2244813002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/timing/PerformanceBase.cpp:347: if
(isLongTaskTimingBufferFull() || !hasObserverFor(PerformanceEntry::LongTask))

Don't we need to dispatch a longtasktimingbufferfull event when
isLongTaskTimingBufferFull() returns false?

https://codereview.chromium.org/2244813002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/timing/PerformanceBase.cpp:354: if
(!isLongTaskTimingBufferFull())

This check won't be needed since you've already checked it at line 347.

https://codereview.chromium.org/2244813002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/timing/PerformanceLongTaskTiming.cpp
(right):

https://codereview.chromium.org/2244813002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/timing/PerformanceLongTaskTiming.cpp:3: *
Copyright (C) 2016 Intel Inc. All rights reserved.

Why are you adding a copyright for Intel?

Either way, we should just use the three-line copyright.

[panicker, 2016-08-17 19:00:09]

Thanks for the review! PTAL.

https://codereview.chromium.org/2244813002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/timing/Performance.idl (right):

https://codereview.chromium.org/2244813002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/timing/Performance.idl:80:
[RuntimeEnabled=LongTaskObserver] void clearLongTaskTimings();
On 2016/08/17 01:15:48, haraken wrote:
> 
> Would it make more sense to rename this to clearLongTaskTimingBuffer? (for
> consistency with the following two methods)

Hmm not sure, I've tried to be consistent with the other perf-entries in this
file:  clearResourceTimings(), clearMarks() etc.

https://codereview.chromium.org/2244813002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/timing/PerformanceBase.cpp (right):

https://codereview.chromium.org/2244813002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/timing/PerformanceBase.cpp:347: if
(isLongTaskTimingBufferFull() || !hasObserverFor(PerformanceEntry::LongTask))
On 2016/08/17 01:15:48, haraken wrote:
> 
> Don't we need to dispatch a longtasktimingbufferfull event when
> isLongTaskTimingBufferFull() returns false?

This is happening at line 362 below.
Basically after adding each item, we check if full and if so dispatch the event
right away.
(Meanwhile if more entries are attempted to be added -- I don't think we need to
keep dispatching the event)

https://codereview.chromium.org/2244813002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/timing/PerformanceBase.cpp:354: if
(!isLongTaskTimingBufferFull())
On 2016/08/17 01:15:48, haraken wrote:
> 
> This check won't be needed since you've already checked it at line 347.

Done.

https://codereview.chromium.org/2244813002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/timing/PerformanceLongTaskTiming.cpp
(right):

https://codereview.chromium.org/2244813002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/timing/PerformanceLongTaskTiming.cpp:3: *
Copyright (C) 2016 Intel Inc. All rights reserved.
On 2016/08/17 01:15:48, haraken wrote:
> 
> Why are you adding a copyright for Intel?
> 
> Either way, we should just use the three-line copyright.

Other similar files in this directory have this copyright, so I wondered if this
directory was special. Happy to get rid of it :)
Done.

[haraken, 2016-08-18 01:00:00]

The implementation looks good.

Can we add layout tests for this?

[panicker, 2016-08-18 17:51:29]

On 2016/08/18 01:00:00, haraken wrote:
> The implementation looks good.
> 
> Can we add layout tests for this?

I have a web-platform-test almost ready that I will send as separate CL shortly.
My understanding is that writing web-platform-test is preferable over Layout
Tests and Sim Tests (also just double checked with Ojan)

[panickercorp, 2016-08-18 18:05:21]

On 2016/08/18 17:51:29, Shubhie wrote:
> On 2016/08/18 01:00:00, haraken wrote:
> > The implementation looks good.
> > 
> > Can we add layout tests for this?
> 
> I have a web-platform-test almost ready that I will send as separate CL
shortly.
> My understanding is that writing web-platform-test is preferable over Layout
> Tests and Sim Tests (also just double checked with Ojan)

So one of the basic tests is roughly this:
https://x20web.corp.google.com/~panicker/tests/perfob-longtask.html

However it doesn't work yet because the plumbing is not hooked up yet and
nothing calls addLongTaskTiming currently.
Do you think I should submit the test now or wait until it's a useful test?

[haraken, 2016-08-19 01:09:09]

On 2016/08/18 18:05:21, panicker wrote:
> On 2016/08/18 17:51:29, Shubhie wrote:
> > On 2016/08/18 01:00:00, haraken wrote:
> > > The implementation looks good.
> > > 
> > > Can we add layout tests for this?
> > 
> > I have a web-platform-test almost ready that I will send as separate CL
> shortly.
> > My understanding is that writing web-platform-test is preferable over Layout
> > Tests and Sim Tests (also just double checked with Ojan)
> 
> So one of the basic tests is roughly this:
> https://x20web.corp.google.com/~panicker/tests/perfob-longtask.html
> 
> However it doesn't work yet because the plumbing is not hooked up yet and
> nothing calls addLongTaskTiming currently.
> Do you think I should submit the test now or wait until it's a useful test?

I'd prefer doing it now. Code should be committed with tests.

[panicker, 2016-08-23 03:00:05]

On 2016/08/19 01:09:09, haraken wrote:
> On 2016/08/18 18:05:21, panicker wrote:
> > On 2016/08/18 17:51:29, Shubhie wrote:
> > > On 2016/08/18 01:00:00, haraken wrote:
> > > > The implementation looks good.
> > > > 
> > > > Can we add layout tests for this?
> > > 
> > > I have a web-platform-test almost ready that I will send as separate CL
> > shortly.
> > > My understanding is that writing web-platform-test is preferable over
Layout
> > > Tests and Sim Tests (also just double checked with Ojan)
> > 
> > So one of the basic tests is roughly this:
> > https://x20web.corp.google.com/~panicker/tests/perfob-longtask.html
> > 
> > However it doesn't work yet because the plumbing is not hooked up yet and
> > nothing calls addLongTaskTiming currently.
> > Do you think I should submit the test now or wait until it's a useful test?
> 
> I'd prefer doing it now. Code should be committed with tests.

Okay I've dug into this and learned couple things:
- Layout Test is more suitable here than web-platform-test, as this API doesn't
even have a basic spec yet.
- Attempting to write a Layout test is premature (as it results in timeouts)
because the event doesn't occur yet -- because the feature is not yet
implemented.
This CL is just the initial scaffold for the timing API, subsequent changes will
actually enable and wire the long task instrumentation.
My understanding is that Layout test is essentially an end-to-end browser
integration test, and the feature needs to exist to make that feasible.

At this stage, unittests are more appropriate, so I'm happy to add more
unittests (already added basic unittest) if you have specific things you'd like
to see tested.
What do you think?

[haraken, 2016-08-23 04:05:02]

On 2016/08/23 03:00:05, Shubhie wrote:
> On 2016/08/19 01:09:09, haraken wrote:
> > On 2016/08/18 18:05:21, panicker wrote:
> > > On 2016/08/18 17:51:29, Shubhie wrote:
> > > > On 2016/08/18 01:00:00, haraken wrote:
> > > > > The implementation looks good.
> > > > > 
> > > > > Can we add layout tests for this?
> > > > 
> > > > I have a web-platform-test almost ready that I will send as separate CL
> > > shortly.
> > > > My understanding is that writing web-platform-test is preferable over
> Layout
> > > > Tests and Sim Tests (also just double checked with Ojan)
> > > 
> > > So one of the basic tests is roughly this:
> > > https://x20web.corp.google.com/~panicker/tests/perfob-longtask.html
> > > 
> > > However it doesn't work yet because the plumbing is not hooked up yet and
> > > nothing calls addLongTaskTiming currently.
> > > Do you think I should submit the test now or wait until it's a useful
test?
> > 
> > I'd prefer doing it now. Code should be committed with tests.
> 
> Okay I've dug into this and learned couple things:
> - Layout Test is more suitable here than web-platform-test, as this API
doesn't
> even have a basic spec yet.
> - Attempting to write a Layout test is premature (as it results in timeouts)
> because the event doesn't occur yet -- because the feature is not yet
> implemented.
> This CL is just the initial scaffold for the timing API, subsequent changes
will
> actually enable and wire the long task instrumentation.
> My understanding is that Layout test is essentially an end-to-end browser
> integration test, and the feature needs to exist to make that feasible.
> 
> At this stage, unittests are more appropriate, so I'm happy to add more
> unittests (already added basic unittest) if you have specific things you'd
like
> to see tested.
> What do you think?

The unittest makes sense at this point but on the other hand I'm not really
happy about landing unused code to the code base. What's a timeline for
implementing the event? Ideally we should make the event workable in this CL and
land it with a layout test.

[panicker, 2016-08-23 04:17:51]

On 2016/08/23 04:05:02, haraken wrote:
> On 2016/08/23 03:00:05, Shubhie wrote:
> > On 2016/08/19 01:09:09, haraken wrote:
> > > On 2016/08/18 18:05:21, panicker wrote:
> > > > On 2016/08/18 17:51:29, Shubhie wrote:
> > > > > On 2016/08/18 01:00:00, haraken wrote:
> > > > > > The implementation looks good.
> > > > > > 
> > > > > > Can we add layout tests for this?
> > > > > 
> > > > > I have a web-platform-test almost ready that I will send as separate
CL
> > > > shortly.
> > > > > My understanding is that writing web-platform-test is preferable over
> > Layout
> > > > > Tests and Sim Tests (also just double checked with Ojan)
> > > > 
> > > > So one of the basic tests is roughly this:
> > > > https://x20web.corp.google.com/~panicker/tests/perfob-longtask.html
> > > > 
> > > > However it doesn't work yet because the plumbing is not hooked up yet
and
> > > > nothing calls addLongTaskTiming currently.
> > > > Do you think I should submit the test now or wait until it's a useful
> test?
> > > 
> > > I'd prefer doing it now. Code should be committed with tests.
> > 
> > Okay I've dug into this and learned couple things:
> > - Layout Test is more suitable here than web-platform-test, as this API
> doesn't
> > even have a basic spec yet.
> > - Attempting to write a Layout test is premature (as it results in timeouts)
> > because the event doesn't occur yet -- because the feature is not yet
> > implemented.
> > This CL is just the initial scaffold for the timing API, subsequent changes
> will
> > actually enable and wire the long task instrumentation.
> > My understanding is that Layout test is essentially an end-to-end browser
> > integration test, and the feature needs to exist to make that feasible.
> > 
> > At this stage, unittests are more appropriate, so I'm happy to add more
> > unittests (already added basic unittest) if you have specific things you'd
> like
> > to see tested.
> > What do you think?
> 
> The unittest makes sense at this point but on the other hand I'm not really
> happy about landing unused code to the code base. What's a timeline for
> implementing the event? Ideally we should make the event workable in this CL
and
> land it with a layout test.

The timeline is imminent: I'm actively working on this (as top priority) and CLs
should land within next ~2 weeks.
I don't think it's a good idea to combine all the changes in one giant CL, as
this is a non-trivial feature and requires input from specialists for certain
aspects (eg. scheduler team for scheduler probes)
CLs in question are:
- Inspector Agent and Probes for V8ScriptController:
https://codereview.chromium.org/2248553002/ [Status: SUBMITTED]
- Probes for Scheduler: https://codereview.chromium.org/2259013003/ [Status: IN
REVIEW]
- final CL will update InspectorWebPerfAgent with the necessary bits (combining
info from tasks and script probes) and call into PerformanceLongTaskTiming. For
wiring proof-of-concept see: https://codereview.chromium.org/2238883005/
Hope that provides necessary context.

[haraken, 2016-08-23 04:20:42]

On 2016/08/23 04:17:51, Shubhie wrote:
> On 2016/08/23 04:05:02, haraken wrote:
> > On 2016/08/23 03:00:05, Shubhie wrote:
> > > On 2016/08/19 01:09:09, haraken wrote:
> > > > On 2016/08/18 18:05:21, panicker wrote:
> > > > > On 2016/08/18 17:51:29, Shubhie wrote:
> > > > > > On 2016/08/18 01:00:00, haraken wrote:
> > > > > > > The implementation looks good.
> > > > > > > 
> > > > > > > Can we add layout tests for this?
> > > > > > 
> > > > > > I have a web-platform-test almost ready that I will send as separate
> CL
> > > > > shortly.
> > > > > > My understanding is that writing web-platform-test is preferable
over
> > > Layout
> > > > > > Tests and Sim Tests (also just double checked with Ojan)
> > > > > 
> > > > > So one of the basic tests is roughly this:
> > > > > https://x20web.corp.google.com/~panicker/tests/perfob-longtask.html
> > > > > 
> > > > > However it doesn't work yet because the plumbing is not hooked up yet
> and
> > > > > nothing calls addLongTaskTiming currently.
> > > > > Do you think I should submit the test now or wait until it's a useful
> > test?
> > > > 
> > > > I'd prefer doing it now. Code should be committed with tests.
> > > 
> > > Okay I've dug into this and learned couple things:
> > > - Layout Test is more suitable here than web-platform-test, as this API
> > doesn't
> > > even have a basic spec yet.
> > > - Attempting to write a Layout test is premature (as it results in
timeouts)
> > > because the event doesn't occur yet -- because the feature is not yet
> > > implemented.
> > > This CL is just the initial scaffold for the timing API, subsequent
changes
> > will
> > > actually enable and wire the long task instrumentation.
> > > My understanding is that Layout test is essentially an end-to-end browser
> > > integration test, and the feature needs to exist to make that feasible.
> > > 
> > > At this stage, unittests are more appropriate, so I'm happy to add more
> > > unittests (already added basic unittest) if you have specific things you'd
> > like
> > > to see tested.
> > > What do you think?
> > 
> > The unittest makes sense at this point but on the other hand I'm not really
> > happy about landing unused code to the code base. What's a timeline for
> > implementing the event? Ideally we should make the event workable in this CL
> and
> > land it with a layout test.
> 
> The timeline is imminent: I'm actively working on this (as top priority) and
CLs
> should land within next ~2 weeks.
> I don't think it's a good idea to combine all the changes in one giant CL, as
> this is a non-trivial feature and requires input from specialists for certain
> aspects (eg. scheduler team for scheduler probes)
> CLs in question are:
> - Inspector Agent and Probes for V8ScriptController:
> https://codereview.chromium.org/2248553002/ [Status: SUBMITTED]
> - Probes for Scheduler: https://codereview.chromium.org/2259013003/ [Status:
IN
> REVIEW]
> - final CL will update InspectorWebPerfAgent with the necessary bits
(combining
> info from tasks and script probes) and call into PerformanceLongTaskTiming.
For
> wiring proof-of-concept see: https://codereview.chromium.org/2238883005/
> Hope that provides necessary context.

If you plan to land those CLs in a reasonable timeline, LGTM.

My point is just that we shouldn't leave unused code to the code base for a long
time. This sometimes happens.

[panicker, 2016-08-23 04:23:52]

On 2016/08/23 04:20:42, haraken wrote:
> On 2016/08/23 04:17:51, Shubhie wrote:
> > On 2016/08/23 04:05:02, haraken wrote:
> > > On 2016/08/23 03:00:05, Shubhie wrote:
> > > > On 2016/08/19 01:09:09, haraken wrote:
> > > > > On 2016/08/18 18:05:21, panicker wrote:
> > > > > > On 2016/08/18 17:51:29, Shubhie wrote:
> > > > > > > On 2016/08/18 01:00:00, haraken wrote:
> > > > > > > > The implementation looks good.
> > > > > > > > 
> > > > > > > > Can we add layout tests for this?
> > > > > > > 
> > > > > > > I have a web-platform-test almost ready that I will send as
separate
> > CL
> > > > > > shortly.
> > > > > > > My understanding is that writing web-platform-test is preferable
> over
> > > > Layout
> > > > > > > Tests and Sim Tests (also just double checked with Ojan)
> > > > > > 
> > > > > > So one of the basic tests is roughly this:
> > > > > > https://x20web.corp.google.com/~panicker/tests/perfob-longtask.html
> > > > > > 
> > > > > > However it doesn't work yet because the plumbing is not hooked up
yet
> > and
> > > > > > nothing calls addLongTaskTiming currently.
> > > > > > Do you think I should submit the test now or wait until it's a
useful
> > > test?
> > > > > 
> > > > > I'd prefer doing it now. Code should be committed with tests.
> > > > 
> > > > Okay I've dug into this and learned couple things:
> > > > - Layout Test is more suitable here than web-platform-test, as this API
> > > doesn't
> > > > even have a basic spec yet.
> > > > - Attempting to write a Layout test is premature (as it results in
> timeouts)
> > > > because the event doesn't occur yet -- because the feature is not yet
> > > > implemented.
> > > > This CL is just the initial scaffold for the timing API, subsequent
> changes
> > > will
> > > > actually enable and wire the long task instrumentation.
> > > > My understanding is that Layout test is essentially an end-to-end
browser
> > > > integration test, and the feature needs to exist to make that feasible.
> > > > 
> > > > At this stage, unittests are more appropriate, so I'm happy to add more
> > > > unittests (already added basic unittest) if you have specific things
you'd
> > > like
> > > > to see tested.
> > > > What do you think?
> > > 
> > > The unittest makes sense at this point but on the other hand I'm not
really
> > > happy about landing unused code to the code base. What's a timeline for
> > > implementing the event? Ideally we should make the event workable in this
CL
> > and
> > > land it with a layout test.
> > 
> > The timeline is imminent: I'm actively working on this (as top priority) and
> CLs
> > should land within next ~2 weeks.
> > I don't think it's a good idea to combine all the changes in one giant CL,
as
> > this is a non-trivial feature and requires input from specialists for
certain
> > aspects (eg. scheduler team for scheduler probes)
> > CLs in question are:
> > - Inspector Agent and Probes for V8ScriptController:
> > https://codereview.chromium.org/2248553002/ [Status: SUBMITTED]
> > - Probes for Scheduler: https://codereview.chromium.org/2259013003/ [Status:
> IN
> > REVIEW]
> > - final CL will update InspectorWebPerfAgent with the necessary bits
> (combining
> > info from tasks and script probes) and call into PerformanceLongTaskTiming.
> For
> > wiring proof-of-concept see: https://codereview.chromium.org/2238883005/
> > Hope that provides necessary context.
> 
> If you plan to land those CLs in a reasonable timeline, LGTM.
> 
> My point is just that we shouldn't leave unused code to the code base for a
long
> time. This sometimes happens.

Thanks! I absolutely will land those CLs as soon as I possibly can.
This is my no. 1 OKR for this quarter. See:
https://easyokrs.googleplex.com/o/2287827/

[panicker, 2016-08-23 17:22:02]

The CQ bit was checked by panicker@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-23 17:22:51]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-23 17:26:27]

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

[commit-bot: I haz the power, 2016-08-23 17:26:28]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)
  chromeos_x86-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_x86-ge...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[panicker, 2016-08-23 18:16:05]

The CQ bit was checked by panicker@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-23 18:16:29]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-23 20:05:01]

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

[commit-bot: I haz the power, 2016-08-23 20:05:02]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[panicker, 2016-08-23 22:46:19]

The CQ bit was checked by panicker@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-23 22:47:24]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-24 00:26:36]

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

[commit-bot: I haz the power, 2016-08-24 00:26:36]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[panicker, 2016-08-24 20:20:38]

The CQ bit was checked by panicker@chromium.org

[panicker, 2016-08-24 20:20:39]

The patchset sent to the CQ was uploaded after l-g-t-m from nduca@chromium.org,
haraken@chromium.org
Link to the patchset: https://codereview.chromium.org/2244813002/#ps140001
(title: "fix merge issue in flags")

[commit-bot: I haz the power, 2016-08-24 20:21:17]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-24 23:00:34]

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

[commit-bot: I haz the power, 2016-08-24 23:00:35]

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

[panicker, 2016-08-25 00:55:33]

The CQ bit was checked by panicker@chromium.org

[commit-bot: I haz the power, 2016-08-25 00:56:32]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-25 02:17:26]

Description was changed from

==========
LongTaskTiming: add idl, Experiment flag, PerformanceEntry and basic
implementation

BUG=635596
==========

to

==========
LongTaskTiming: add idl, Experiment flag, PerformanceEntry and basic
implementation

BUG=635596
==========

[commit-bot: I haz the power, 2016-08-25 02:17:28]

Committed patchset #8 (id:140001)

[commit-bot: I haz the power, 2016-08-25 02:20:55]

Description was changed from

==========
LongTaskTiming: add idl, Experiment flag, PerformanceEntry and basic
implementation

BUG=635596
==========

to

==========
LongTaskTiming: add idl, Experiment flag, PerformanceEntry and basic
implementation

BUG=635596

Committed: https://crrev.com/67ecd9023c61fcf77899dbeca071f5f35aabb8f0
Cr-Commit-Position: refs/heads/master@{#414257}
==========

[commit-bot: I haz the power, 2016-08-25 02:20:57]

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