Supplement should have a Member to the corresponding Supplementable object (Part 1)

Supplement should have a Member to the corresponding Supplementable object (Part 1)

If Supplement has a Member to the corresponding Supplementable object,
we can remove a bunch of LifecycleObservers (because the Supplement object can
get the Supplementable object without observing the Supplementable object).
We should add the Member.

BUG=627723

[haraken, 2016-07-13 07:15:48]

haraken@chromium.org changed reviewers:
+ sigbjornf@opera.com

[haraken, 2016-07-13 07:15:49]

PTAL

[sof, 2016-07-13 07:20:41]

https://codereview.chromium.org/2150443002/diff/1/third_party/WebKit/Source/p...
File third_party/WebKit/Source/platform/Supplementable.h (right):

https://codereview.chromium.org/2150443002/diff/1/third_party/WebKit/Source/p...
third_party/WebKit/Source/platform/Supplementable.h:123: WeakMember<T> m_host;
Thinking about this some more, what value does it bring over status quo to have
a WeakMember<> here? i.e., could you clarify how you intend to make use of
|m_host| in supplement impls?

[haraken, 2016-07-13 07:24:26]

https://codereview.chromium.org/2150443002/diff/1/third_party/WebKit/Source/p...
File third_party/WebKit/Source/platform/Supplementable.h (right):

https://codereview.chromium.org/2150443002/diff/1/third_party/WebKit/Source/p...
third_party/WebKit/Source/platform/Supplementable.h:123: WeakMember<T> m_host;
On 2016/07/13 07:20:41, sof wrote:
> Thinking about this some more, what value does it bring over status quo to
have
> a WeakMember<> here? i.e., could you clarify how you intend to make use of
> |m_host| in supplement impls?

Many Supplement classes that inherit from DOMWindowProperty and
LocalFrameLifecycleObserver are inheriting from them just because they want to
get the host object. If Supplement provides the host object, we can remove the
inheritance.

It's nasty that we need to make many NavigatorXXX objects inherit from
DOMWindowProperty/LocalFrameLifecycleObserver. They should be able to just get
the host object from Supplement.

[sof, 2016-07-13 07:39:41]

https://codereview.chromium.org/2150443002/diff/1/third_party/WebKit/Source/p...
File third_party/WebKit/Source/platform/Supplementable.h (right):

https://codereview.chromium.org/2150443002/diff/1/third_party/WebKit/Source/p...
third_party/WebKit/Source/platform/Supplementable.h:123: WeakMember<T> m_host;
On 2016/07/13 07:24:26, haraken wrote:
> On 2016/07/13 07:20:41, sof wrote:
> > Thinking about this some more, what value does it bring over status quo to
> have
> > a WeakMember<> here? i.e., could you clarify how you intend to make use of
> > |m_host| in supplement impls?
> 
> Many Supplement classes that inherit from DOMWindowProperty and
> LocalFrameLifecycleObserver are inheriting from them just because they want to
> get the host object. If Supplement provides the host object, we can remove the
> inheritance.
> 
> It's nasty that we need to make many NavigatorXXX objects inherit from
> DOMWindowProperty/LocalFrameLifecycleObserver. They should be able to just get
> the host object from Supplement.

ok, thanks for clarifying the purpose, i.e., |m_host| is not a lifetime-extender
for supplement, but a way to avoid keeping ad-hoc "parent pointers".

[sof, 2016-07-13 07:41:57]

https://codereview.chromium.org/2150443002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/dom/CSSSelectorWatch.cpp (right):

https://codereview.chromium.org/2150443002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/dom/CSSSelectorWatch.cpp:49: ,
m_document(document)
Do you need m_document any longer?

[haraken, 2016-07-13 07:42:12]

https://codereview.chromium.org/2150443002/diff/1/third_party/WebKit/Source/p...
File third_party/WebKit/Source/platform/Supplementable.h (right):

https://codereview.chromium.org/2150443002/diff/1/third_party/WebKit/Source/p...
third_party/WebKit/Source/platform/Supplementable.h:123: WeakMember<T> m_host;
On 2016/07/13 07:39:41, sof wrote:
> On 2016/07/13 07:24:26, haraken wrote:
> > On 2016/07/13 07:20:41, sof wrote:
> > > Thinking about this some more, what value does it bring over status quo to
> > have
> > > a WeakMember<> here? i.e., could you clarify how you intend to make use of
> > > |m_host| in supplement impls?
> > 
> > Many Supplement classes that inherit from DOMWindowProperty and
> > LocalFrameLifecycleObserver are inheriting from them just because they want
to
> > get the host object. If Supplement provides the host object, we can remove
the
> > inheritance.
> > 
> > It's nasty that we need to make many NavigatorXXX objects inherit from
> > DOMWindowProperty/LocalFrameLifecycleObserver. They should be able to just
get
> > the host object from Supplement.
> 
> ok, thanks for clarifying the purpose, i.e., |m_host| is not a
lifetime-extender
> for supplement, but a way to avoid keeping ad-hoc "parent pointers".

Yes, right.

[haraken, 2016-07-13 07:44:55]

https://codereview.chromium.org/2150443002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/dom/CSSSelectorWatch.cpp (right):

https://codereview.chromium.org/2150443002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/dom/CSSSelectorWatch.cpp:49: ,
m_document(document)
On 2016/07/13 07:41:57, sof wrote:
> Do you need m_document any longer?

This is exactly what I wanted to remove :) Removed.

[sof, 2016-07-13 07:46:09]

lgtm

https://codereview.chromium.org/2150443002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/dom/CSSSelectorWatch.h (right):

https://codereview.chromium.org/2150443002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/dom/CSSSelectorWatch.h:63: Document& document()
const { return *host(); }
assert/check for non-nullness?

[haraken, 2016-07-13 07:51:25]

https://codereview.chromium.org/2150443002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/dom/CSSSelectorWatch.h (right):

https://codereview.chromium.org/2150443002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/dom/CSSSelectorWatch.h:63: Document& document()
const { return *host(); }
On 2016/07/13 07:46:08, sof wrote:
> assert/check for non-nullness?

Hmm, maybe CSSSelectorWatch does want to keep a strong reference to Document?
Then we should keep Member<Document>.

What we can remove is a weak reference to the host object (e.g., XXXObservers).

[sof, 2016-07-13 07:54:07]

https://codereview.chromium.org/2150443002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/dom/CSSSelectorWatch.h (right):

https://codereview.chromium.org/2150443002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/dom/CSSSelectorWatch.h:63: Document& document()
const { return *host(); }
On 2016/07/13 07:51:25, haraken wrote:
> On 2016/07/13 07:46:08, sof wrote:
> > assert/check for non-nullness?
> 
> Hmm, maybe CSSSelectorWatch does want to keep a strong reference to Document?
> Then we should keep Member<Document>.
> 
> What we can remove is a weak reference to the host object (e.g.,
XXXObservers).

How about going with "Member<T> m_host" ?

[haraken, 2016-07-13 08:11:24]

On 2016/07/13 07:54:07, sof wrote:
>
https://codereview.chromium.org/2150443002/diff/20001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/core/dom/CSSSelectorWatch.h (right):
> 
>
https://codereview.chromium.org/2150443002/diff/20001/third_party/WebKit/Sour...
> third_party/WebKit/Source/core/dom/CSSSelectorWatch.h:63: Document& document()
> const { return *host(); }
> On 2016/07/13 07:51:25, haraken wrote:
> > On 2016/07/13 07:46:08, sof wrote:
> > > assert/check for non-nullness?
> > 
> > Hmm, maybe CSSSelectorWatch does want to keep a strong reference to
Document?
> > Then we should keep Member<Document>.
> > 
> > What we can remove is a weak reference to the host object (e.g.,
> XXXObservers).
> 
> How about going with "Member<T> m_host" ?

Done. (Honestly speaking, I don't have a strong opinion on Member or
WeakMember.)

[haraken, 2016-07-13 08:11:28]

The CQ bit was checked by haraken@chromium.org

[haraken, 2016-07-13 08:11:29]

The patchset sent to the CQ was uploaded after l-g-t-m from sigbjornf@opera.com
Link to the patchset: https://codereview.chromium.org/2150443002/#ps40001
(title: "temp")

[commit-bot: I haz the power, 2016-07-13 08:11:49]

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

[sof, 2016-07-13 08:16:18]

On 2016/07/13 08:11:24, haraken wrote:
> On 2016/07/13 07:54:07, sof wrote:
> >
>
https://codereview.chromium.org/2150443002/diff/20001/third_party/WebKit/Sour...
> > File third_party/WebKit/Source/core/dom/CSSSelectorWatch.h (right):
> > 
> >
>
https://codereview.chromium.org/2150443002/diff/20001/third_party/WebKit/Sour...
> > third_party/WebKit/Source/core/dom/CSSSelectorWatch.h:63: Document&
document()
> > const { return *host(); }
> > On 2016/07/13 07:51:25, haraken wrote:
> > > On 2016/07/13 07:46:08, sof wrote:
> > > > assert/check for non-nullness?
> > > 
> > > Hmm, maybe CSSSelectorWatch does want to keep a strong reference to
> Document?
> > > Then we should keep Member<Document>.
> > > 
> > > What we can remove is a weak reference to the host object (e.g.,
> > XXXObservers).
> > 
> > How about going with "Member<T> m_host" ?
> 
> Done. (Honestly speaking, I don't have a strong opinion on Member or
> WeakMember.)

ok, update the title & description before landing? :)

[sof, 2016-07-13 08:17:00]

On 2016/07/13 08:16:18, sof wrote:
> On 2016/07/13 08:11:24, haraken wrote:
> > On 2016/07/13 07:54:07, sof wrote:
> > >
> >
>
https://codereview.chromium.org/2150443002/diff/20001/third_party/WebKit/Sour...
> > > File third_party/WebKit/Source/core/dom/CSSSelectorWatch.h (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/2150443002/diff/20001/third_party/WebKit/Sour...
> > > third_party/WebKit/Source/core/dom/CSSSelectorWatch.h:63: Document&
> document()
> > > const { return *host(); }
> > > On 2016/07/13 07:51:25, haraken wrote:
> > > > On 2016/07/13 07:46:08, sof wrote:
> > > > > assert/check for non-nullness?
> > > > 
> > > > Hmm, maybe CSSSelectorWatch does want to keep a strong reference to
> > Document?
> > > > Then we should keep Member<Document>.
> > > > 
> > > > What we can remove is a weak reference to the host object (e.g.,
> > > XXXObservers).
> > > 
> > > How about going with "Member<T> m_host" ?
> > 
> > Done. (Honestly speaking, I don't have a strong opinion on Member or
> > WeakMember.)
> 
> ok, update the title & description before landing? :)

Including a sentence or two on why m_host is introduced, would also be good.

[haraken, 2016-07-13 08:18:24]

Description was changed from

==========
Supplement should have a WeakMember to the corresponding Supplementable object
(Part 1)

BUG=627723
==========

to

==========
Supplement should have a Member to the corresponding Supplementable object (Part
1)

If Supplement has a Member to the corresponding Supplementable object,
we can remove a bunch of LifecycleObservers (because the Supplement object can
get the Supplementable object without observing the Supplementable object).
We should add the Member.

BUG=627723
==========

[haraken, 2016-07-13 08:18:44]

On 2016/07/13 08:17:00, sof wrote:
> On 2016/07/13 08:16:18, sof wrote:
> > On 2016/07/13 08:11:24, haraken wrote:
> > > On 2016/07/13 07:54:07, sof wrote:
> > > >
> > >
> >
>
https://codereview.chromium.org/2150443002/diff/20001/third_party/WebKit/Sour...
> > > > File third_party/WebKit/Source/core/dom/CSSSelectorWatch.h (right):
> > > > 
> > > >
> > >
> >
>
https://codereview.chromium.org/2150443002/diff/20001/third_party/WebKit/Sour...
> > > > third_party/WebKit/Source/core/dom/CSSSelectorWatch.h:63: Document&
> > document()
> > > > const { return *host(); }
> > > > On 2016/07/13 07:51:25, haraken wrote:
> > > > > On 2016/07/13 07:46:08, sof wrote:
> > > > > > assert/check for non-nullness?
> > > > > 
> > > > > Hmm, maybe CSSSelectorWatch does want to keep a strong reference to
> > > Document?
> > > > > Then we should keep Member<Document>.
> > > > > 
> > > > > What we can remove is a weak reference to the host object (e.g.,
> > > > XXXObservers).
> > > > 
> > > > How about going with "Member<T> m_host" ?
> > > 
> > > Done. (Honestly speaking, I don't have a strong opinion on Member or
> > > WeakMember.)
> > 
> > ok, update the title & description before landing? :)
> 
> Including a sentence or two on why m_host is introduced, would also be good.

Done.

[commit-bot: I haz the power, 2016-07-13 08:21:27]

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

[commit-bot: I haz the power, 2016-07-13 08:21:28]

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

[haraken, 2016-07-13 08:23:13]

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

[haraken, 2016-07-13 08:23:14]

jochen@: PTAL at public/. This is just changing a signature of Blink-internal
APIs.

[haraken, 2016-07-14 01:24:52]

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

[haraken, 2016-07-14 01:24:53]

tkent@: Would you take a look at public/?

[tkent, 2016-07-14 01:31:28]

tkent@chromium.org changed reviewers:
+ dcheng@chromium.org

[tkent, 2016-07-14 01:33:04]

https://codereview.chromium.org/2150443002/diff/60001/third_party/WebKit/publ...
File third_party/WebKit/public/web/WebFrameWidget.h (right):

https://codereview.chromium.org/2150443002/diff/60001/third_party/WebKit/publ...
third_party/WebKit/public/web/WebFrameWidget.h:85: virtual
CompositorProxyClient* createCompositorProxyClient(WorkerClients&) = 0;
+dcheng.

Exposing a core class WorkerClients looks wrong, but probably this is
unavoidable according to the TODO comment above?

[dcheng, 2016-07-14 04:16:01]

On 2016/07/14 01:33:04, tkent wrote:
>
https://codereview.chromium.org/2150443002/diff/60001/third_party/WebKit/publ...
> File third_party/WebKit/public/web/WebFrameWidget.h (right):
> 
>
https://codereview.chromium.org/2150443002/diff/60001/third_party/WebKit/publ...
> third_party/WebKit/public/web/WebFrameWidget.h:85: virtual
> CompositorProxyClient* createCompositorProxyClient(WorkerClients&) = 0;
> +dcheng.
> 
> Exposing a core class WorkerClients looks wrong, but probably this is
> unavoidable according to the TODO comment above?

Yeah, it's a pretty easy fix. This CL is fine as-is: I will fix the web layer
after this CL lands to not expose it like that.

[tkent, 2016-07-14 04:18:29]

lgtm

[haraken, 2016-07-14 05:12:40]

The CQ bit was checked by haraken@chromium.org

[haraken, 2016-07-14 05:12:40]

The patchset sent to the CQ was uploaded after l-g-t-m from sigbjornf@opera.com,
tkent@chromium.org
Link to the patchset: https://codereview.chromium.org/2150443002/#ps80001
(title: "temp")

[commit-bot: I haz the power, 2016-07-14 05:12:55]

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-07-14 05:50:14]

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

[commit-bot: I haz the power, 2016-07-14 05:50:16]

Try jobs failed on following builders:
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[haraken, 2016-07-14 05:51:07]

The CQ bit was checked by haraken@chromium.org

[commit-bot: I haz the power, 2016-07-14 05:51:24]

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-07-14 06:10:52]

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

[commit-bot: I haz the power, 2016-07-14 06:10:54]

Try jobs failed on following builders:
  win_clang on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_clang/builds/...)

[haraken, 2016-07-14 10:06:42]

The CQ bit was checked by haraken@chromium.org

[haraken, 2016-07-14 10:06:43]

The patchset sent to the CQ was uploaded after l-g-t-m from tkent@chromium.org,
sigbjornf@opera.com
Link to the patchset: https://codereview.chromium.org/2150443002/#ps100001
(title: "temp")

[commit-bot: I haz the power, 2016-07-14 10:06:57]

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-07-14 10:48:43]

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

[commit-bot: I haz the power, 2016-07-14 10:48:45]

Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[haraken, 2016-07-15 04:48:17]

The CQ bit was checked by haraken@chromium.org

[haraken, 2016-07-15 04:48:18]

The patchset sent to the CQ was uploaded after l-g-t-m from tkent@chromium.org,
sigbjornf@opera.com
Link to the patchset: https://codereview.chromium.org/2150443002/#ps120001
(title: "temp")

[commit-bot: I haz the power, 2016-07-15 04:48: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-07-15 05:20:30]

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

[commit-bot: I haz the power, 2016-07-15 05:20:31]

Try jobs failed on following builders:
  win_chromium_compile_dbg_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[jochen (gone - plz use gerrit), 2016-07-15 14:36:11]

lgtm

[sof, 2016-07-25 09:19:28]

Wouldn't bringing the supplementable class defn into scope when defining the
supplements take care of the compile failures w/ MSVC's eager instantiation?
e.g., add #include "core/frame/Navigator.h" to NavigatorGamepad.h -- or does
that create additional compilation woes?

[haraken, 2016-07-25 11:39:09]

On 2016/07/25 09:19:28, sof wrote:
> Wouldn't bringing the supplementable class defn into scope when defining the
> supplements take care of the compile failures w/ MSVC's eager instantiation?
> e.g., add #include "core/frame/Navigator.h" to NavigatorGamepad.h -- or does
> that create additional compilation woes?

Yes, we need something like that. I just didn't have enough time to fix all
compilation issues on the Win bots :)

[sof, 2016-07-25 12:49:38]

On 2016/07/25 11:39:09, haraken wrote:
> On 2016/07/25 09:19:28, sof wrote:
> > Wouldn't bringing the supplementable class defn into scope when defining the
> > supplements take care of the compile failures w/ MSVC's eager instantiation?
> > e.g., add #include "core/frame/Navigator.h" to NavigatorGamepad.h -- or does
> > that create additional compilation woes?
> 
> Yes, we need something like that. I just didn't have enough time to fix all
> compilation issues on the Win bots :)

i see, good - i wasn't sure if you'd given up on defeating MSVC :)

[haraken, 2016-08-03 07:34:22]

The CQ bit was checked by haraken@chromium.org

[haraken, 2016-08-03 07:34:22]

The patchset sent to the CQ was uploaded after l-g-t-m from tkent@chromium.org,
sigbjornf@opera.com, jochen@chromium.org
Link to the patchset: https://codereview.chromium.org/2150443002/#ps140001
(title: "temp")

[commit-bot: I haz the power, 2016-08-03 07:34:34]

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-03 07:46:00]

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

[commit-bot: I haz the power, 2016-08-03 07:46:01]

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

[haraken, 2016-08-03 07:49:14]

The CQ bit was checked by haraken@chromium.org

[haraken, 2016-08-03 07:49:14]

The patchset sent to the CQ was uploaded after l-g-t-m from tkent@chromium.org,
sigbjornf@opera.com, jochen@chromium.org
Link to the patchset: https://codereview.chromium.org/2150443002/#ps160001
(title: "temp")

[commit-bot: I haz the power, 2016-08-03 07:49:28]

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-03 08:22:59]

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

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

Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[haraken, 2016-08-03 08:29:03]

The CQ bit was checked by haraken@chromium.org

[haraken, 2016-08-03 08:29:03]

The patchset sent to the CQ was uploaded after l-g-t-m from tkent@chromium.org,
sigbjornf@opera.com, jochen@chromium.org
Link to the patchset: https://codereview.chromium.org/2150443002/#ps200001
(title: "temp")

[haraken, 2016-08-22 01:29:31]

The CQ bit was checked by haraken@chromium.org

[haraken, 2016-08-22 01:29:31]

The patchset sent to the CQ was uploaded after l-g-t-m from tkent@chromium.org,
sigbjornf@opera.com, jochen@chromium.org
Link to the patchset: https://codereview.chromium.org/2150443002/#ps220001
(title: "temp")

[commit-bot: I haz the power, 2016-08-22 01:29:40]

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-22 02:11:21]

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

[commit-bot: I haz the power, 2016-08-22 02:11:22]

Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[haraken, 2016-08-22 04:48:32]

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

[commit-bot: I haz the power, 2016-08-22 04:48:40]

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-22 05:34:41]

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

[commit-bot: I haz the power, 2016-08-22 05:34:42]

Dry run: Try jobs failed on following builders:
  win_chromium_compile_dbg_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[haraken, 2016-08-22 05:47:18]

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

[commit-bot: I haz the power, 2016-08-22 05:47:40]

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-22 06:34:38]

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

[commit-bot: I haz the power, 2016-08-22 06:34:39]

Dry run: Try jobs failed on following builders:
  win_clang on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_clang/builds/...)

[haraken, 2016-08-22 06:40:21]

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

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

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-22 07:17:30]

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

[commit-bot: I haz the power, 2016-08-22 07:17:31]

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...)