Exclude wifi_data_provider_linux.cc for chromecast build as chromecast uses wpa_supplicant instead …

Exclude wifi_data_provider_linux.cc for chromecast build as chromecast uses wpa_supplicant instead of network manager (which is used in the linux version).

BUG=336640

[lcwu1, 2014-04-22 01:39:38]

In patch set #2 we moved chromecast-specific implementation of various content
APIs/classes to their respective locations (from the original chromecast/port
directory). Please take a look. Thanks.

[jam, 2014-04-22 19:44:19]

On 2014/04/22 01:39:38, lcwu1 wrote:
> In patch set #2 we moved chromecast-specific implementation of various content
> APIs/classes to their respective locations (from the original chromecast/port
> directory). Please take a look. Thanks.

Originally, I had said "-cc files that implement methods in headers in other
directories need to live in
those other directories (unless it's an interface). this is the pattern we use
for every other port.". After the discussions with Darin, he had brought up the
point that it won't scale to have every port add its own _port.cc files in other
directories outside its own code. SO going by that:
-render_widget_host_view_cast.cc & web_contents_view_cast.cc: these should
implement the content/port interfaces for
RenderWidgetHostViewPort/WebContentsViewPort and live in
src/chromecast/shell/browser
-wifi_data_provider_cast.cc: can this be transitioned to use content/port's
LocationProvider?
-power_save_blocker_cast.cc, webcursor_cast.cc, & font_list_cast.cc: can you use
the ozone versions which are already in the tree?
-native_web_keyboard_event_cast.cc: perhaps we need an ozone version of this?

[Ben Goodger (Google), 2014-04-22 21:34:04]

Can you explain why RenderWidgetHostViewAura is insufficient? What dependencies
does RWHVA impose that are undesirable, and why?

[lcwu1, 2014-04-23 01:32:06]

On 2014/04/22 19:44:19, jam wrote:
> On 2014/04/22 01:39:38, lcwu1 wrote:
> > In patch set #2 we moved chromecast-specific implementation of various
content
> > APIs/classes to their respective locations (from the original
chromecast/port
> > directory). Please take a look. Thanks.
> 
> Originally, I had said "-cc files that implement methods in headers in other
> directories need to live in
> those other directories (unless it's an interface). this is the pattern we use
> for every other port.". After the discussions with Darin, he had brought up
the
> point that it won't scale to have every port add its own _port.cc files in
other
> directories outside its own code. SO going by that:
> -render_widget_host_view_cast.cc & web_contents_view_cast.cc: these should
> implement the content/port interfaces for
> RenderWidgetHostViewPort/WebContentsViewPort and live in
> src/chromecast/shell/browser

Yes, we can surely put these files in chromecast/shell/browser. However, as we
discussed earlier, the pros of having these port implementations together in the
same directory is that when the APIs are changed, it's much easier for the
developers to identify and fix all the uses of the changes APIs. And it seems to
me that this benefit outweighs the cons of having many port files in a
directory. Or do you still think it's best to move them to the chromecast
directory?

> -wifi_data_provider_cast.cc: can this be transitioned to use content/port's
> LocationProvider?

By implementing the WifiDataProvider interface allows us to easily hook up our
wifi controller component (i.e. wpa_supplicant) to the browser to provide
high-resolution (fine-grained) location info. If we implement the generic
LocationProvider, in order to provide the high-resolution location info, we
probably will have to re-implement/duplicate the same code/features that wifi
data provider and/or GeolocationProvider has already provided in content, which
seems undesirable.

> -power_save_blocker_cast.cc, webcursor_cast.cc, & font_list_cast.cc: can you
use
> the ozone versions which are already in the tree?

Chromecast's implementation for these features are simply stubs to satisfy the
linker as we don't need/care about them. The ozone version of both
power_save_blocker and font_list are currently stub implementation, which we
could use currently. However, they could be changed (e.g. power_save_blocker) in
a way that's no longer suitable for us. Ozone has an actual webcursor
implementation which we don't need/use.

Maybe a more general solution is to specifically create xxx_stub.cc for these
features so that any port that doesn't care/need these features can simply pick
up the stub implementation.

> -native_web_keyboard_event_cast.cc: perhaps we need an ozone version of this?

Similar to the above, creating a native_web_keyboard_event_stub.cc that any port
that doesn't care about keyboard events can use seems to be a more general
approach.

(Having these files ending with _cast.cc does have one benefit though. With the
file_name rules, we could simply list them in the sources list in the gyp files
without additional conditions/rules to include/exclude them.)

Please let me know what you think. Thanks.

[lcwu1, 2014-04-23 01:44:33]

On 2014/04/22 21:34:04, Ben Goodger (Google) wrote:
> Can you explain why RenderWidgetHostViewAura is insufficient? What
dependencies
> does RWHVA impose that are undesirable, and why?

The reason why aura is not enabled on chromecast is not because
RenderWidgetHostViewAura is insufficient, it's simply because when we started
two years ago, aura was just started so we have our own RenderWidgetHostView
implementation. Enabling aura is definitely something on our road map.

[lcwu1, 2014-04-23 06:14:29]

On 2014/04/23 01:32:06, lcwu1 wrote:
> On 2014/04/22 19:44:19, jam wrote:
> > On 2014/04/22 01:39:38, lcwu1 wrote:
> > > In patch set #2 we moved chromecast-specific implementation of various
> content
> > > APIs/classes to their respective locations (from the original
> chromecast/port
> > > directory). Please take a look. Thanks.
> > 
> > Originally, I had said "-cc files that implement methods in headers in other
> > directories need to live in
> > those other directories (unless it's an interface). this is the pattern we
use
> > for every other port.". After the discussions with Darin, he had brought up
> the
> > point that it won't scale to have every port add its own _port.cc files in
> other
> > directories outside its own code. SO going by that:
> > -render_widget_host_view_cast.cc & web_contents_view_cast.cc: these should
> > implement the content/port interfaces for
> > RenderWidgetHostViewPort/WebContentsViewPort and live in
> > src/chromecast/shell/browser
> 
> Yes, we can surely put these files in chromecast/shell/browser. However, as we
> discussed earlier, the pros of having these port implementations together in
the
> same directory is that when the APIs are changed, it's much easier for the
> developers to identify and fix all the uses of the changes APIs. And it seems
to
> me that this benefit outweighs the cons of having many port files in a
> directory. Or do you still think it's best to move them to the chromecast
> directory?
> 
> > -wifi_data_provider_cast.cc: can this be transitioned to use content/port's
> > LocationProvider?
> 
> By implementing the WifiDataProvider interface allows us to easily hook up our
> wifi controller component (i.e. wpa_supplicant) to the browser to provide
> high-resolution (fine-grained) location info. If we implement the generic
> LocationProvider, in order to provide the high-resolution location info, we
> probably will have to re-implement/duplicate the same code/features that wifi
> data provider and/or GeolocationProvider has already provided in content,
which
> seems undesirable.
> 
> > -power_save_blocker_cast.cc, webcursor_cast.cc, & font_list_cast.cc: can you
> use
> > the ozone versions which are already in the tree?
> 
> Chromecast's implementation for these features are simply stubs to satisfy the
> linker as we don't need/care about them. The ozone version of both
> power_save_blocker and font_list are currently stub implementation, which we
> could use currently. However, they could be changed (e.g. power_save_blocker)
in
> a way that's no longer suitable for us. Ozone has an actual webcursor
> implementation which we don't need/use.
> 
> Maybe a more general solution is to specifically create xxx_stub.cc for these
> features so that any port that doesn't care/need these features can simply
pick
> up the stub implementation.
> 
> > -native_web_keyboard_event_cast.cc: perhaps we need an ozone version of
this?
> 
> Similar to the above, creating a native_web_keyboard_event_stub.cc that any
port
> that doesn't care about keyboard events can use seems to be a more general
> approach.
> 
> (Having these files ending with _cast.cc does have one benefit though. With
the
> file_name rules, we could simply list them in the sources list in the gyp
files
> without additional conditions/rules to include/exclude them.)
> 
> Please let me know what you think. Thanks.

I thought more about these features/supports that chromecast doesn't care/need
but has to provide stub implementations in order to satisfy the linker. I think
probably a better approach is to, besides providing a generic stub
implementation, create gyp variables (e.g. enable_power_save_blocker,
use_webcursor, etc.) to control whether these features/supports are needed for a
port/platform. When these gyp variables are set to 0 by a port/platform (e.g. in
build/common.gypi), the default/stub implementation is then used. Does this
sound like a good approach to reduce the number of xxx_cast.cc files?

[Ben Goodger (Google), 2014-04-23 17:15:13]

On 2014/04/23 01:44:33, lcwu1 wrote:
> On 2014/04/22 21:34:04, Ben Goodger (Google) wrote:
> > Can you explain why RenderWidgetHostViewAura is insufficient? What
> dependencies
> > does RWHVA impose that are undesirable, and why?
> 
> The reason why aura is not enabled on chromecast is not because
> RenderWidgetHostViewAura is insufficient, it's simply because when we started
> two years ago, aura was just started so we have our own RenderWidgetHostView
> implementation. Enabling aura is definitely something on our road map.

Have you tried building with aura enabled? I think this might be worth the
exercise if only to have a more complete discussion about the challenges.

Our strategy for porting within Chrome for some time has been to converge on
Aura as the window abstraction from content on up. Recently we've removed two
legacy RenderWidgetHostView implementations: RenderWidgetHostViewWin (bound to a
HWND) and RenderWidgetHostViewGtk (GtkWidget). Going forward we'd like to
further reduce the number of RWHV impls, rather than adding more, as this
greatly simplifies things at the content layer for all developers. For example
there is exploratory work under way looking at eliminating RWHVMac.

[jam, 2014-04-23 21:19:29]

On 2014/04/23 01:32:06, lcwu1 wrote:
> On 2014/04/22 19:44:19, jam wrote:
> > On 2014/04/22 01:39:38, lcwu1 wrote:
> > > In patch set #2 we moved chromecast-specific implementation of various
> content
> > > APIs/classes to their respective locations (from the original
> chromecast/port
> > > directory). Please take a look. Thanks.
> > 
> > Originally, I had said "-cc files that implement methods in headers in other
> > directories need to live in
> > those other directories (unless it's an interface). this is the pattern we
use
> > for every other port.". After the discussions with Darin, he had brought up
> the
> > point that it won't scale to have every port add its own _port.cc files in
> other
> > directories outside its own code. SO going by that:
> > -render_widget_host_view_cast.cc & web_contents_view_cast.cc: these should
> > implement the content/port interfaces for
> > RenderWidgetHostViewPort/WebContentsViewPort and live in
> > src/chromecast/shell/browser
> 
> Yes, we can surely put these files in chromecast/shell/browser. However, as we
> discussed earlier, the pros of having these port implementations together in
the
> same directory is that when the APIs are changed, it's much easier for the
> developers to identify and fix all the uses of the changes APIs.

If there are trybots, the location won't matter.

But note that the implementations of public interfaces (i.e. interfaces in
content/public or content/port) are by definition never going to be in the same
directories.

> And it seems to
> me that this benefit outweighs the cons of having many port files in a
> directory. Or do you still think it's best to move them to the chromecast
> directory?

Please do; this was the outcome of the meeting we had last week.

> 
> > -wifi_data_provider_cast.cc: can this be transitioned to use content/port's
> > LocationProvider?
> 
> By implementing the WifiDataProvider interface allows us to easily hook up our
> wifi controller component (i.e. wpa_supplicant) to the browser to provide
> high-resolution (fine-grained) location info. If we implement the generic
> LocationProvider, in order to provide the high-resolution location info, we
> probably will have to re-implement/duplicate the same code/features that wifi
> data provider and/or GeolocationProvider has already provided in content,
which
> seems undesirable.

I'm not really familiar with this part of the code. Can you explain in more
detail why LocationProvider isn't sufficient? Can we add extra APIs to it to fit
your needs?

> 
> > -power_save_blocker_cast.cc, webcursor_cast.cc, & font_list_cast.cc: can you
> use
> > the ozone versions which are already in the tree?
> 
> Chromecast's implementation for these features are simply stubs to satisfy the
> linker as we don't need/care about them. The ozone version of both
> power_save_blocker and font_list are currently stub implementation, which we
> could use currently.

ok it sounds like you can use them then.

> However, they could be changed (e.g. power_save_blocker) in
> a way that's no longer suitable for us. Ozone has an actual webcursor
> implementation which we don't need/use.

In general, the bar for chromecast to not use aura/ozone should be really high.
Otherwise this cost of maintaining a new port is passed on to all chrome
developers. Given that chromecast would be ozone's first customer, I doubt that
changes to its files would break chromecast; and this problem is moot once you
have trybots.

> 
> Maybe a more general solution is to specifically create xxx_stub.cc for these
> features so that any port that doesn't care/need these features can simply
pick
> up the stub implementation.
> 
> > -native_web_keyboard_event_cast.cc: perhaps we need an ozone version of
this?
> 
> Similar to the above, creating a native_web_keyboard_event_stub.cc that any
port
> that doesn't care about keyboard events can use seems to be a more general
> approach.

Can ozone help here?

> 
> (Having these files ending with _cast.cc does have one benefit though. With
the
> file_name rules, we could simply list them in the sources list in the gyp
files
> without additional conditions/rules to include/exclude them.)

The problem is what i hinted at above: now you're adding a new port that all
chrome devs have to support, instead of reusing ozone or aura or an existing
stub implementations.

> 
> Please let me know what you think. Thanks.

Also adding Robert to see what he thinks.

[spang, 2014-04-25 22:10:48]

On 2014/04/23 01:32:06, lcwu1 wrote:
> On 2014/04/22 19:44:19, jam wrote:
> > On 2014/04/22 01:39:38, lcwu1 wrote:
> > > In patch set #2 we moved chromecast-specific implementation of various
> content
> > > APIs/classes to their respective locations (from the original
> chromecast/port
> > > directory). Please take a look. Thanks.
> > 
> > Originally, I had said "-cc files that implement methods in headers in other
> > directories need to live in
> > those other directories (unless it's an interface). this is the pattern we
use
> > for every other port.". After the discussions with Darin, he had brought up
> the
> > point that it won't scale to have every port add its own _port.cc files in
> other
> > directories outside its own code. SO going by that:
> > -render_widget_host_view_cast.cc & web_contents_view_cast.cc: these should
> > implement the content/port interfaces for
> > RenderWidgetHostViewPort/WebContentsViewPort and live in
> > src/chromecast/shell/browser
> 
> Yes, we can surely put these files in chromecast/shell/browser. However, as we
> discussed earlier, the pros of having these port implementations together in
the
> same directory is that when the APIs are changed, it's much easier for the
> developers to identify and fix all the uses of the changes APIs. And it seems
to
> me that this benefit outweighs the cons of having many port files in a
> directory. Or do you still think it's best to move them to the chromecast
> directory?
> 
> > -wifi_data_provider_cast.cc: can this be transitioned to use content/port's
> > LocationProvider?
> 
> By implementing the WifiDataProvider interface allows us to easily hook up our
> wifi controller component (i.e. wpa_supplicant) to the browser to provide
> high-resolution (fine-grained) location info. If we implement the generic
> LocationProvider, in order to provide the high-resolution location info, we
> probably will have to re-implement/duplicate the same code/features that wifi
> data provider and/or GeolocationProvider has already provided in content,
which
> seems undesirable.
> 
> > -power_save_blocker_cast.cc, webcursor_cast.cc, & font_list_cast.cc: can you
> use
> > the ozone versions which are already in the tree?
> 
> Chromecast's implementation for these features are simply stubs to satisfy the
> linker as we don't need/care about them. The ozone version of both
> power_save_blocker and font_list are currently stub implementation, which we
> could use currently. However, they could be changed (e.g. power_save_blocker)
in
> a way that's no longer suitable for us. Ozone has an actual webcursor
> implementation which we don't need/use.

webcursor_ozone could be used even if you don't care about cursors - we do have
an example platform like that (it draws the window to a PNG file, and has no
cursor).

> 
> Maybe a more general solution is to specifically create xxx_stub.cc for these
> features so that any port that doesn't care/need these features can simply
pick
> up the stub implementation.
> 
> > -native_web_keyboard_event_cast.cc: perhaps we need an ozone version of
this?
> 
> Similar to the above, creating a native_web_keyboard_event_stub.cc that any
port
> that doesn't care about keyboard events can use seems to be a more general
> approach.
> 
> (Having these files ending with _cast.cc does have one benefit though. With
the
> file_name rules, we could simply list them in the sources list in the gyp
files
> without additional conditions/rules to include/exclude them.)
> 
> Please let me know what you think. Thanks.

[rjkroege, 2014-04-25 23:09:13]

I agree with many of the other people making comments.

I recall an earlier discussion with you where we had demonstrated a build of
embedded content shell running on the dongle with and without the use of
hardware acceleration so there is no intrinsic property of the dongle that
precludes use of aura and ozone.

It would seem to me that it would significantly simplify your CL if you used the
embedded=1 code as a basis? Much of this CL for example would not be needed: the
ozone cursor, power management and aura RWHV are all workable in a cast context.
Are there changes here that are essential to cast video functionality?

Perhaps the experiment that beng@ suggested to try to bring up the cast shell
using ozone=1 is worthwhile? I had actually started such an experiment based on
content shell perhaps it would be better to implement starting from
https://codereview.chromium.org/223143003/?

https://codereview.chromium.org/223583003/diff/20001/content/browser/power_sa...
File content/browser/power_save_blocker_cast.cc (right):

https://codereview.chromium.org/223583003/diff/20001/content/browser/power_sa...
content/browser/power_save_blocker_cast.cc:6: #include
"content/browser/power_save_blocker_impl.h"
this ordering is not valid chromium style.

https://codereview.chromium.org/223583003/diff/20001/content/browser/power_sa...
content/browser/power_save_blocker_cast.cc:22:
PowerSaveBlockerImpl::~PowerSaveBlockerImpl() {
this file is very similar to the _ozone implementation. They could be the same?

[lcwu1, 2014-04-26 00:03:36]

On 2014/04/25 22:10:48, spang wrote:
> On 2014/04/23 01:32:06, lcwu1 wrote:
> > On 2014/04/22 19:44:19, jam wrote:
> > > On 2014/04/22 01:39:38, lcwu1 wrote:
> > > > In patch set #2 we moved chromecast-specific implementation of various
> > content
> > > > APIs/classes to their respective locations (from the original
> > chromecast/port
> > > > directory). Please take a look. Thanks.
> > > 
> > > Originally, I had said "-cc files that implement methods in headers in
other
> > > directories need to live in
> > > those other directories (unless it's an interface). this is the pattern we
> use
> > > for every other port.". After the discussions with Darin, he had brought
up
> > the
> > > point that it won't scale to have every port add its own _port.cc files in
> > other
> > > directories outside its own code. SO going by that:
> > > -render_widget_host_view_cast.cc & web_contents_view_cast.cc: these should
> > > implement the content/port interfaces for
> > > RenderWidgetHostViewPort/WebContentsViewPort and live in
> > > src/chromecast/shell/browser
> > 
> > Yes, we can surely put these files in chromecast/shell/browser. However, as
we
> > discussed earlier, the pros of having these port implementations together in
> the
> > same directory is that when the APIs are changed, it's much easier for the
> > developers to identify and fix all the uses of the changes APIs. And it
seems
> to
> > me that this benefit outweighs the cons of having many port files in a
> > directory. Or do you still think it's best to move them to the chromecast
> > directory?
> > 
> > > -wifi_data_provider_cast.cc: can this be transitioned to use
content/port's
> > > LocationProvider?
> > 
> > By implementing the WifiDataProvider interface allows us to easily hook up
our
> > wifi controller component (i.e. wpa_supplicant) to the browser to provide
> > high-resolution (fine-grained) location info. If we implement the generic
> > LocationProvider, in order to provide the high-resolution location info, we
> > probably will have to re-implement/duplicate the same code/features that
wifi
> > data provider and/or GeolocationProvider has already provided in content,
> which
> > seems undesirable.
> > 
> > > -power_save_blocker_cast.cc, webcursor_cast.cc, & font_list_cast.cc: can
you
> > use
> > > the ozone versions which are already in the tree?
> > 
> > Chromecast's implementation for these features are simply stubs to satisfy
the
> > linker as we don't need/care about them. The ozone version of both
> > power_save_blocker and font_list are currently stub implementation, which we
> > could use currently. However, they could be changed (e.g.
power_save_blocker)
> in
> > a way that's no longer suitable for us. Ozone has an actual webcursor
> > implementation which we don't need/use.
> 
> webcursor_ozone could be used even if you don't care about cursors - we do
have
> an example platform like that (it draws the window to a PNG file, and has no
> cursor).

I think my point is that ozone has all the plumbing to connect webcursor with
the underlying platform cursor support, which chromecast doesn't really need.
Basically a dumb/stub implementation will do just fine. But I think as long as
it doesn't incur any noticeable run-time overheads, it probably doesn't matter.
We are looking into enabling ozone.

> 
> > 
> > Maybe a more general solution is to specifically create xxx_stub.cc for
these
> > features so that any port that doesn't care/need these features can simply
> pick
> > up the stub implementation.
> > 
> > > -native_web_keyboard_event_cast.cc: perhaps we need an ozone version of
> this?
> > 
> > Similar to the above, creating a native_web_keyboard_event_stub.cc that any
> port
> > that doesn't care about keyboard events can use seems to be a more general
> > approach.
> > 
> > (Having these files ending with _cast.cc does have one benefit though. With
> the
> > file_name rules, we could simply list them in the sources list in the gyp
> files
> > without additional conditions/rules to include/exclude them.)
> > 
> > Please let me know what you think. Thanks.

[lcwu1, 2014-04-26 00:07:36]

On 2014/04/25 23:09:13, rjkroege wrote:
> I agree with many of the other people making comments.
> 
> I recall an earlier discussion with you where we had demonstrated a build of
> embedded content shell running on the dongle with and without the use of
> hardware acceleration so there is no intrinsic property of the dongle that
> precludes use of aura and ozone.
> 
> It would seem to me that it would significantly simplify your CL if you used
the
> embedded=1 code as a basis? Much of this CL for example would not be needed:
the
> ozone cursor, power management and aura RWHV are all workable in a cast
context.
> Are there changes here that are essential to cast video functionality?

Yes, we are looking into enabling aura and ozone. Originally we can't set
'embedded' to 1 because it would also enable ozone, but we should be able to set
it to 1 now.

> 
> Perhaps the experiment that beng@ suggested to try to bring up the cast shell
> using ozone=1 is worthwhile? I had actually started such an experiment based
on
> content shell perhaps it would be better to implement starting from
> https://codereview.chromium.org/223143003/
> 
>
https://codereview.chromium.org/223583003/diff/20001/content/browser/power_sa...
> File content/browser/power_save_blocker_cast.cc (right):
> 
>
https://codereview.chromium.org/223583003/diff/20001/content/browser/power_sa...
> content/browser/power_save_blocker_cast.cc:6: #include
> "content/browser/power_save_blocker_impl.h"
> this ordering is not valid chromium style.
> 
>
https://codereview.chromium.org/223583003/diff/20001/content/browser/power_sa...
> content/browser/power_save_blocker_cast.cc:22:
> PowerSaveBlockerImpl::~PowerSaveBlockerImpl() {
> this file is very similar to the _ozone implementation. They could be the
same?

[rjkroege, 2014-04-29 19:51:03]

On 2014/04/26 00:07:36, lcwu1 wrote:
> On 2014/04/25 23:09:13, rjkroege wrote:
> > I agree with many of the other people making comments.
> > 
> > I recall an earlier discussion with you where we had demonstrated a build of
> > embedded content shell running on the dongle with and without the use of
> > hardware acceleration so there is no intrinsic property of the dongle that
> > precludes use of aura and ozone.
> > 
> > It would seem to me that it would significantly simplify your CL if you used
> the
> > embedded=1 code as a basis? Much of this CL for example would not be needed:
> the
> > ozone cursor, power management and aura RWHV are all workable in a cast
> context.
> > Are there changes here that are essential to cast video functionality?
> 
> Yes, we are looking into enabling aura and ozone. Originally we can't set
> 'embedded' to 1 because it would also enable ozone, but we should be able to
set
> it to 1 now.

That's great. Am looking forward to seeing the CL.

> 
> > 
> > Perhaps the experiment that beng@ suggested to try to bring up the cast
shell
> > using ozone=1 is worthwhile? I had actually started such an experiment based
> on
> > content shell perhaps it would be better to implement starting from
> > https://codereview.chromium.org/223143003/
> > 
> >
>
https://codereview.chromium.org/223583003/diff/20001/content/browser/power_sa...
> > File content/browser/power_save_blocker_cast.cc (right):
> > 
> >
>
https://codereview.chromium.org/223583003/diff/20001/content/browser/power_sa...
> > content/browser/power_save_blocker_cast.cc:6: #include
> > "content/browser/power_save_blocker_impl.h"
> > this ordering is not valid chromium style.
> > 
> >
>
https://codereview.chromium.org/223583003/diff/20001/content/browser/power_sa...
> > content/browser/power_save_blocker_cast.cc:22:
> > PowerSaveBlockerImpl::~PowerSaveBlockerImpl() {
> > this file is very similar to the _ozone implementation. They could be the
> same?

[lcwu1, 2014-06-24 22:45:16]

This CL is no longer needed as we moved to aura + ozone.