Mojoify PoweMonitorMessageBroadcaster IPC from browser to child process

Mojoify PoweMonitorMessageBroadcaster IPC from browser to child process

Mojoify PoweMonitorMessageBroadcaster is the first step of "Decoupling Power
Monitor from //Content".

PowerMonitorMessageBroadcaster sends messages to both RenderProcess and other
ChildProcess. This CL Mojoifies the messages PowerMonitorMsg_PowerStateChange,
PowerMonitorMsg_Suspend, and PowerMonitorMsg_Resume. To do so we introduce the
PowerMonitorClient Mojo interface and change the PowerMonitorBroadcastSource to
implement the interface.

To avoid configure PowerMonitorClientPtr separately in {child,render}_process_
host_impl.cc, we add the PowerMonitor mojo interface, and add the
BrowserChildProcessHost::ConnectionFilterImpl so it can register the mojo
interface implementation in BrowserChildProcessHostImpl side.

Unit tests for PowerMonitorMessageBroadcaster and PowerMonitorBroadcastSource
are changed accordingly.

Followup will decouple PowerMonitorMessageBroadcaster and
PowerMonitorBroadcastSource from //Content.

BUG=647247
Committed: https://crrev.com/19b5e6a89dcadde523d674878434e7948f387e0d
Cr-Commit-Position: refs/heads/master@{#427965}

[leonhsl(Using Gerrit), 2016-10-20 06:40:48]

The CQ bit was checked by leon.han@intel.com to run a CQ dry run

[commit-bot: I haz the power, 2016-10-20 06:41:00]

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-10-20 07:46:49]

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

[commit-bot: I haz the power, 2016-10-20 07:46:50]

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

[leonhsl(Using Gerrit), 2016-10-20 08:45:58]

The CQ bit was checked by leon.han@intel.com to run a CQ dry run

[commit-bot: I haz the power, 2016-10-20 08:46:10]

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-10-20 09:47:52]

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

[commit-bot: I haz the power, 2016-10-20 09:47:53]

Dry run: This issue passed the CQ dry run.

[leonhsl(Using Gerrit), 2016-10-20 13:36:00]

leon.han@intel.com changed reviewers:
+ blundell@chromium.org

[leonhsl(Using Gerrit), 2016-10-20 13:36:01]

Hi, blundell@, ke.he@intel.com is my teammate who is also interested in chromium
mojo related development and has been ramping up for some days, then he helped
to prepare this CL for our device service work. Would you PTAL at this? Thanks. 
I believe he could help to accelerate the whole work progress ;-)

[blundell, 2016-10-20 22:42:21]

blundell@chromium.org changed reviewers:
+ rockot@chromium.org

[blundell, 2016-10-20 22:42:22]

A good start! I just commented on the highest-level issues, will do a
nitty-gritty review once we nail those down.

+rockot@ for the threading question in power_monitor_broadcast_source.cc.

https://codereview.chromium.org/2433203003/diff/20001/content/browser/power_m...
File content/browser/power_monitor_message_broadcaster.h (right):

https://codereview.chromium.org/2433203003/diff/20001/content/browser/power_m...
content/browser/power_monitor_message_broadcaster.h:28: void
Init(device::mojom::PowerMonitorClientPtr& power_monitor_client);
You can do this communication via mojo, i.e.:

Add have a PowerMonitor interface that has a SetClient(PowerMontiorClient)
method.

Then you don't need to do the configuration in {child,
render}_process_host_impl.cc.

You can make PowerMonitorMessageBroadcaster be strongly bound to its binding to
handle lifetime.

https://codereview.chromium.org/2433203003/diff/20001/content/child/power_mon...
File content/child/power_monitor_broadcast_source.cc (right):

https://codereview.chromium.org/2433203003/diff/20001/content/child/power_mon...
content/child/power_monitor_broadcast_source.cc:13:
PowerMonitorBroadcastSource::PowerMonitorBroadcastSource()
There's a threading change here I think: Before the IPC would come in on the
child process' IO thread, whereas now it will come in on the thread that
PowerMonitorBroadcastSource lives on (presumably the main thread). rockot@, do
you know if having this communication on the main thread in the child process is
OK as a general rule?

[ke.he, 2016-10-24 06:54:39]

https://codereview.chromium.org/2433203003/diff/20001/content/browser/power_m...
File content/browser/power_monitor_message_broadcaster.h (right):

https://codereview.chromium.org/2433203003/diff/20001/content/browser/power_m...
content/browser/power_monitor_message_broadcaster.h:28: void
Init(device::mojom::PowerMonitorClientPtr& power_monitor_client);
On 2016/10/20 22:42:22, blundell wrote:
> You can do this communication via mojo, i.e.:
> 
> Add have a PowerMonitor interface that has a SetClient(PowerMontiorClient)
> method.
> 
> Then you don't need to do the configuration in {child,
> render}_process_host_impl.cc.
> 
> You can make PowerMonitorMessageBroadcaster be strongly bound to its binding
to
> handle lifetime.

Yes it's better to add a "SetClient(PowerMontiorClient)" in mojo interface to
avoid do configurations through Init().
The problem I met is that currently there is no "RegisterMojoInterfaces
functionality" in BrowserChildProcessHostImpl. But we found a similar reference:
there is "GpuProcessHost::ConnectionFilterImpl", and it was added into
ServiceManagerConnection in GpuProcessHost::Init(). I think it is a good
reference to our scenario.
So I plan to add a "BrowserChildProcessHost::ConnectionFilterImpl" to enable the
"mojo interface register" first. Then we can register the "SetClient".
@blundell, @rockot Any comments on this? Thanks!

[ke.he, 2016-10-24 11:32:02]

my git operation mistake caused a new cl at
https://codereview.chromium.org/2447613004/ after Patch Set 2 of
https://codereview.chromium.org/2433203003/#ps20001

In latest cl, the SetClient(PowerMontiorClient) is added in mojo interface,
ConnectionFilterImpl is added into BrowserChildProcessHostImpl.

https://codereview.chromium.org/2433203003/diff/20001/content/browser/power_m...
File content/browser/power_monitor_message_broadcaster.h (right):

https://codereview.chromium.org/2433203003/diff/20001/content/browser/power_m...
content/browser/power_monitor_message_broadcaster.h:28: void
Init(device::mojom::PowerMonitorClientPtr& power_monitor_client);
On 2016/10/24 06:54:39, ke.he wrote:
> On 2016/10/20 22:42:22, blundell wrote:
> > You can do this communication via mojo, i.e.:
> > 
> > Add have a PowerMonitor interface that has a SetClient(PowerMontiorClient)
> > method.
> > 
> > Then you don't need to do the configuration in {child,
> > render}_process_host_impl.cc.
> > 
> > You can make PowerMonitorMessageBroadcaster be strongly bound to its binding
> to
> > handle lifetime.
> 
> Yes it's better to add a "SetClient(PowerMontiorClient)" in mojo interface to
> avoid do configurations through Init().
> The problem I met is that currently there is no "RegisterMojoInterfaces
> functionality" in BrowserChildProcessHostImpl. But we found a similar
reference:
> there is "GpuProcessHost::ConnectionFilterImpl", and it was added into
> ServiceManagerConnection in GpuProcessHost::Init(). I think it is a good
> reference to our scenario.
> So I plan to add a "BrowserChildProcessHost::ConnectionFilterImpl" to enable
the
> "mojo interface register" first. Then we can register the "SetClient".
> @blundell, @rockot Any comments on this? Thanks!


Sorry the uploaded cl is branched, the latest one is at
https://codereview.chromium.org/2447613004/

[leonhsl(Using Gerrit), 2016-10-25 05:12:43]

The CQ bit was checked by leon.han@intel.com to run a CQ dry run

[commit-bot: I haz the power, 2016-10-25 05:12:59]

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-10-25 05:15:30]

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

[commit-bot: I haz the power, 2016-10-25 05:15:30]

Dry run: Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[leonhsl(Using Gerrit), 2016-10-25 07:34:16]

The CQ bit was checked by leon.han@intel.com to run a CQ dry run

[commit-bot: I haz the power, 2016-10-25 07:34:28]

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

[ke.he, 2016-10-25 08:08:23]

Description was changed from

==========
Mojoify PoweMonitorMessageBroadcaster IPC from browser to child process

Mojoify PoweMonitorMessageBroadcaster is the first step of "Decoupling Power
Monitor from //Content".
PowerMonitorMessageBroadcaster send messages to both RenderProcess and other
ChildProcess. This CL Mojoifies the messages PowerMonitorMsg_PowerStateChange,
PowerMonitorMsg_Suspend, and PowerMonitorMsg_Resume. To do so we introduce the
PowerMonitorClient Mojo interface and change the PowerMonitorBroadcastSource to
implement the interface.
Unit tests for PowerMonitorMessageBroadcaster and PowerMonitorBroadcastSource
are changed accordingly.

Followup will decouple PowerMonitorMessageBroadcaster and
PowerMonitorBroadcastSource from //Content.

BUG=647247
==========

to

==========
Mojoify PoweMonitorMessageBroadcaster IPC from browser to child process

Mojoify PoweMonitorMessageBroadcaster is the first step of "Decoupling Power
Monitor from //Content".

PowerMonitorMessageBroadcaster sends messages to both RenderProcess and other
ChildProcess. This CL Mojoifies the messages PowerMonitorMsg_PowerStateChange,
PowerMonitorMsg_Suspend, and PowerMonitorMsg_Resume. To do so we introduce the
PowerMonitorClient Mojo interface and change the PowerMonitorBroadcastSource to
implement the interface.

To avoid configure PowerMonitorClientPtr separately in {child,render}_process_
host_impl.cc, we add the PowerMonitor mojo interface, and add the
BrowserChildProcessHost::ConnectionFilterImpl so it can register the mojo
interface implementation in BrowserChildProcessHostImpl side.

Unit tests for PowerMonitorMessageBroadcaster and PowerMonitorBroadcastSource
are changed accordingly.

Followup will decouple PowerMonitorMessageBroadcaster and
PowerMonitorBroadcastSource from //Content.

BUG=647247
==========

[commit-bot: I haz the power, 2016-10-25 09:16:26]

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

[commit-bot: I haz the power, 2016-10-25 09:16:27]

Dry run: 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_...)

[leonhsl(Using Gerrit), 2016-10-25 10:27:52]

The CQ bit was checked by leon.han@intel.com to run a CQ dry run

[commit-bot: I haz the power, 2016-10-25 10:28:12]

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-10-25 11:17:04]

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

[commit-bot: I haz the power, 2016-10-25 11:17:05]

Dry run: This issue passed the CQ dry run.

[ke.he, 2016-10-25 14:14:07]

Use "git cl issue" resolved the my git operation mistake, so still keep the code
review/comments in this thread.
Could you PTAL this patch? thanks!

[ke.he, 2016-10-25 14:14:11]

Use "git cl issue" resolved the my git operation mistake, so still keep the code
review/comments in this thread.
Could you PTAL this patch? thanks!

[Ken Rockot(use gerrit already), 2016-10-25 16:53:13]

This is great. LGTM!

https://codereview.chromium.org/2433203003/diff/80001/device/power_monitor/pu...
File device/power_monitor/public/interfaces/power_monitor.mojom (right):

https://codereview.chromium.org/2433203003/diff/80001/device/power_monitor/pu...
device/power_monitor/public/interfaces/power_monitor.mojom:9:
AddClient(PowerMonitorClient client);
nit: I think SetClient is more accurate. AddClient implies you can call it more
than once to bind multiple clients on the same PowerMonitor interface, but that
doesn't appear to be the case.

[blundell, 2016-10-25 16:53:44]

Nice!

Ken, could you review whether the setup in browser_child_process_host.cc looks
good and also the comment I left for you on power_monitor_broadcast_source.cc?

https://codereview.chromium.org/2433203003/diff/80001/content/browser/browser...
File content/browser/browser_child_process_host_impl.h (right):

https://codereview.chromium.org/2433203003/diff/80001/content/browser/browser...
content/browser/browser_child_process_host_impl.h:123: class
ConnectionFilterImpl;
nit: necessary?

https://codereview.chromium.org/2433203003/diff/80001/content/browser/power_m...
File content/browser/power_monitor_message_broadcaster.h (right):

https://codereview.chromium.org/2433203003/diff/80001/content/browser/power_m...
content/browser/power_monitor_message_broadcaster.h:26: // Implement
device::mojom::PowerMonitor.
nit:

device::mojom::PowerMonitor:

https://codereview.chromium.org/2433203003/diff/80001/content/child/power_mon...
File content/child/power_monitor_broadcast_source.cc (right):

https://codereview.chromium.org/2433203003/diff/80001/content/child/power_mon...
content/child/power_monitor_broadcast_source.cc:22:
power_monitor->AddClient(binding_.CreateInterfacePtrAndBind());
There's a threading change here I think: Before the IPC would come in on the
child process' IO thread, whereas now it will come in on the thread that
PowerMonitorBroadcastSource lives on (presumably the main thread). rockot@, do
you know if having this communication on the main thread in the child process is
OK as a general rule?

https://codereview.chromium.org/2433203003/diff/80001/content/child/power_mon...
File content/child/power_monitor_broadcast_source.h (right):

https://codereview.chromium.org/2433203003/diff/80001/content/child/power_mon...
content/child/power_monitor_broadcast_source.h:32:
mojo::Binding<device::mojom::PowerMonitorClient> binding_;
This can be just a StrongBinding and ChildThreadImpl doesn't have to own this
object anymore.

[Ken Rockot(use gerrit already), 2016-10-25 16:56:14]

https://codereview.chromium.org/2433203003/diff/80001/content/child/power_mon...
File content/child/power_monitor_broadcast_source.cc (right):

https://codereview.chromium.org/2433203003/diff/80001/content/child/power_mon...
content/child/power_monitor_broadcast_source.cc:22:
power_monitor->AddClient(binding_.CreateInterfacePtrAndBind());
On 2016/10/25 at 16:53:44, blundell wrote:
> There's a threading change here I think: Before the IPC would come in on the
> child process' IO thread, whereas now it will come in on the thread that
> PowerMonitorBroadcastSource lives on (presumably the main thread). rockot@, do
> you know if having this communication on the main thread in the child process
is
> OK as a general rule?

Yeah this is fine. The new dispatch behavior is effectively the same as before.

[blundell, 2016-10-25 16:58:14]

On 2016/10/25 16:56:14, Ken Rockot wrote:
>
https://codereview.chromium.org/2433203003/diff/80001/content/child/power_mon...
> File content/child/power_monitor_broadcast_source.cc (right):
> 
>
https://codereview.chromium.org/2433203003/diff/80001/content/child/power_mon...
> content/child/power_monitor_broadcast_source.cc:22:
> power_monitor->AddClient(binding_.CreateInterfacePtrAndBind());
> On 2016/10/25 at 16:53:44, blundell wrote:
> > There's a threading change here I think: Before the IPC would come in on the
> > child process' IO thread, whereas now it will come in on the thread that
> > PowerMonitorBroadcastSource lives on (presumably the main thread). rockot@,
do
> > you know if having this communication on the main thread in the child
process
> is
> > OK as a general rule?
> 
> Yeah this is fine. The new dispatch behavior is effectively the same as
before.

LGTM with the nits I posted above

To explicitly record the conversation that Ken and I just had, the Mojo IPC will
come in on the IO thread (as all Mojo IPC does) and then end up posting tasks to
the thread that PowerMonitorBroadcastSource is running on.

[blundell, 2016-10-25 17:00:36]

Did you sign the CLA?

https://cla.developers.google.com/about/google-individual?csw=1

[ke.he, 2016-10-26 05:22:31]

On 2016/10/25 17:00:36, blundell wrote:
> Did you sign the CLA?
> 
> https://cla.developers.google.com/about/google-individual?csw=1

Yes, it shows as below:

You are covered by the following corporate agreements:
Agreement	Name	Date Signed
Google Corporate CLA	Intel CLA Submissions	Nov 25, 2014 14:48 PST

[leonhsl(Using Gerrit), 2016-10-26 08:44:28]

The CQ bit was checked by leon.han@intel.com to run a CQ dry run

[commit-bot: I haz the power, 2016-10-26 08:44:45]

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-10-26 09:53:41]

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

[commit-bot: I haz the power, 2016-10-26 09:53:43]

Dry run: This issue passed the CQ dry run.

[ke.he, 2016-10-26 10:01:51]

https://codereview.chromium.org/2433203003/diff/80001/content/browser/browser...
File content/browser/browser_child_process_host_impl.h (right):

https://codereview.chromium.org/2433203003/diff/80001/content/browser/browser...
content/browser/browser_child_process_host_impl.h:123: class
ConnectionFilterImpl;
On 2016/10/25 16:53:44, blundell wrote:
> nit: necessary?

Done.

https://codereview.chromium.org/2433203003/diff/80001/content/browser/power_m...
File content/browser/power_monitor_message_broadcaster.h (right):

https://codereview.chromium.org/2433203003/diff/80001/content/browser/power_m...
content/browser/power_monitor_message_broadcaster.h:26: // Implement
device::mojom::PowerMonitor.
On 2016/10/25 16:53:44, blundell wrote:
> nit:
> 
> device::mojom::PowerMonitor:

Done.

https://codereview.chromium.org/2433203003/diff/80001/content/child/power_mon...
File content/child/power_monitor_broadcast_source.h (right):

https://codereview.chromium.org/2433203003/diff/80001/content/child/power_mon...
content/child/power_monitor_broadcast_source.h:32:
mojo::Binding<device::mojom::PowerMonitorClient> binding_;
On 2016/10/25 16:53:44, blundell wrote:
> This can be just a StrongBinding and ChildThreadImpl doesn't have to own this
> object anymore.

@blundell, Big thanks for your comments:)
Here the ChildThreadImpl doesn't directly own this object, ChildThreadImpl owns
power_monitor_ (std::unique_ptr<base::PowerMonitor>), then power_monitor_ owns
this object. From the current code logic, the lifetime of this
PowerMonitorBroadcastSource object is same as the ChildThreadImpl, so the
StrongBinding lost its meanings in this scenario. It seems the "common" Binding
is also acceptable here.  How do you think about this? Thanks again!

https://codereview.chromium.org/2433203003/diff/80001/device/power_monitor/pu...
File device/power_monitor/public/interfaces/power_monitor.mojom (right):

https://codereview.chromium.org/2433203003/diff/80001/device/power_monitor/pu...
device/power_monitor/public/interfaces/power_monitor.mojom:9:
AddClient(PowerMonitorClient client);
On 2016/10/25 16:53:13, Ken Rockot wrote:
> nit: I think SetClient is more accurate. AddClient implies you can call it
more
> than once to bind multiple clients on the same PowerMonitor interface, but
that
> doesn't appear to be the case.

Done.

[leonhsl(Using Gerrit), 2016-10-26 10:10:49]

leon.han@intel.com changed reviewers:
+ jam@chromium.org, tsepez@chromium.org

[leonhsl(Using Gerrit), 2016-10-26 10:10:50]

+jam@ : For overall OWNER review

+tsepez@ : For security review

Thanks!

[Tom Sepez, 2016-10-26 15:57:21]

mojom LGTM

[jam, 2016-10-26 16:14:27]

lgtm

[blundell, 2016-10-26 16:18:02]

still lgtm

https://codereview.chromium.org/2433203003/diff/80001/content/child/power_mon...
File content/child/power_monitor_broadcast_source.h (right):

https://codereview.chromium.org/2433203003/diff/80001/content/child/power_mon...
content/child/power_monitor_broadcast_source.h:32:
mojo::Binding<device::mojom::PowerMonitorClient> binding_;
On 2016/10/26 10:01:51, ke.he wrote:
> On 2016/10/25 16:53:44, blundell wrote:
> > This can be just a StrongBinding and ChildThreadImpl doesn't have to own
this
> > object anymore.
> 
> @blundell, Big thanks for your comments:)
> Here the ChildThreadImpl doesn't directly own this object, ChildThreadImpl
owns
> power_monitor_ (std::unique_ptr<base::PowerMonitor>), then power_monitor_ owns
> this object. From the current code logic, the lifetime of this
> PowerMonitorBroadcastSource object is same as the ChildThreadImpl, so the
> StrongBinding lost its meanings in this scenario. It seems the "common"
Binding
> is also acceptable here.  How do you think about this? Thanks again!

Thanks for the clarification. The current structure makes sense.

[ke.he, 2016-10-27 02:42:40]

The CQ bit was checked by ke.he@intel.com

[ke.he, 2016-10-27 02:42:41]

The patchset sent to the CQ was uploaded after l-g-t-m from rockot@chromium.org
Link to the patchset: https://codereview.chromium.org/2433203003/#ps100001
(title: "Modify AddClient, Connectionfilter innerClass")

[commit-bot: I haz the power, 2016-10-27 02:43:10]

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-10-27 02:51:51]

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

[commit-bot: I haz the power, 2016-10-27 02:51:52]

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

[ke.he, 2016-10-27 03:01:56]

The CQ bit was checked by ke.he@intel.com

[ke.he, 2016-10-27 03:01:57]

The patchset sent to the CQ was uploaded after l-g-t-m from tsepez@chromium.org,
rockot@chromium.org, jam@chromium.org, blundell@chromium.org
Link to the patchset: https://codereview.chromium.org/2433203003/#ps120001
(title: "code rebase")

[ke.he, 2016-10-27 03:02:01]

The CQ bit was unchecked by ke.he@intel.com

[ke.he, 2016-10-27 03:03:48]

The CQ bit was checked by ke.he@intel.com

[commit-bot: I haz the power, 2016-10-27 03:04:11]

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-10-27 04:22:18]

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

[commit-bot: I haz the power, 2016-10-27 04:22:20]

Try jobs failed on following builders:
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)

[ke.he, 2016-10-27 05:00:54]

The CQ bit was checked by ke.he@intel.com

[commit-bot: I haz the power, 2016-10-27 05:01:15]

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-10-27 06:21:53]

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

[commit-bot: I haz the power, 2016-10-27 06:21:54]

Try jobs failed on following builders:
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)

[ke.he, 2016-10-27 06:26:18]

The CQ bit was checked by ke.he@intel.com

[commit-bot: I haz the power, 2016-10-27 06:26:42]

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-10-27 07:02:43]

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

[commit-bot: I haz the power, 2016-10-27 07:02:45]

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

[ke.he, 2016-10-27 07:30:30]

The CQ bit was checked by ke.he@intel.com

[commit-bot: I haz the power, 2016-10-27 07:30: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-10-27 07:56:25]

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

[commit-bot: I haz the power, 2016-10-27 07:56:27]

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

[ke.he, 2016-10-27 08:10:15]

The CQ bit was checked by ke.he@intel.com

[commit-bot: I haz the power, 2016-10-27 08:10:42]

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-10-27 08:47:31]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2016-10-27 08:51:02]

Description was changed from

==========
Mojoify PoweMonitorMessageBroadcaster IPC from browser to child process

Mojoify PoweMonitorMessageBroadcaster is the first step of "Decoupling Power
Monitor from //Content".

PowerMonitorMessageBroadcaster sends messages to both RenderProcess and other
ChildProcess. This CL Mojoifies the messages PowerMonitorMsg_PowerStateChange,
PowerMonitorMsg_Suspend, and PowerMonitorMsg_Resume. To do so we introduce the
PowerMonitorClient Mojo interface and change the PowerMonitorBroadcastSource to
implement the interface.

To avoid configure PowerMonitorClientPtr separately in {child,render}_process_
host_impl.cc, we add the PowerMonitor mojo interface, and add the
BrowserChildProcessHost::ConnectionFilterImpl so it can register the mojo
interface implementation in BrowserChildProcessHostImpl side.

Unit tests for PowerMonitorMessageBroadcaster and PowerMonitorBroadcastSource
are changed accordingly.

Followup will decouple PowerMonitorMessageBroadcaster and
PowerMonitorBroadcastSource from //Content.

BUG=647247
==========

to

==========
Mojoify PoweMonitorMessageBroadcaster IPC from browser to child process

Mojoify PoweMonitorMessageBroadcaster is the first step of "Decoupling Power
Monitor from //Content".

PowerMonitorMessageBroadcaster sends messages to both RenderProcess and other
ChildProcess. This CL Mojoifies the messages PowerMonitorMsg_PowerStateChange,
PowerMonitorMsg_Suspend, and PowerMonitorMsg_Resume. To do so we introduce the
PowerMonitorClient Mojo interface and change the PowerMonitorBroadcastSource to
implement the interface.

To avoid configure PowerMonitorClientPtr separately in {child,render}_process_
host_impl.cc, we add the PowerMonitor mojo interface, and add the
BrowserChildProcessHost::ConnectionFilterImpl so it can register the mojo
interface implementation in BrowserChildProcessHostImpl side.

Unit tests for PowerMonitorMessageBroadcaster and PowerMonitorBroadcastSource
are changed accordingly.

Followup will decouple PowerMonitorMessageBroadcaster and
PowerMonitorBroadcastSource from //Content.

BUG=647247

Committed: https://crrev.com/19b5e6a89dcadde523d674878434e7948f387e0d
Cr-Commit-Position: refs/heads/master@{#427965}
==========

[commit-bot: I haz the power, 2016-10-27 08:51:04]

Patchset 7 (id:??) landed as
https://crrev.com/19b5e6a89dcadde523d674878434e7948f387e0d
Cr-Commit-Position: refs/heads/master@{#427965}