Add OnDisplayMetricsChanged in DisplayObserver.

Add OnDisplayMetricsChanged in DisplayObserver.

This replaces OnDisplayBoundsChanged and add a MetricsType
parameter so consumers can now which metrics has changed. The
current set of MetricsType include bounds, workarea and rotation.

BUG=162827
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=271768

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=272040

[mlamouri (slow - plz ping), 2014-04-29 15:54:13]

oshima@, does that sound reasonable to you? There are a lot of tests to fix and
code to update (I have unlikely modified everything that needs to be modified).

I don't need a proper review, just your opinion about the general idea.

[oshima, 2014-04-29 17:19:49]

On 2014/04/29 15:54:13, Mounir Lamouri wrote:
> oshima@, does that sound reasonable to you? There are a lot of tests to fix
and
> code to update (I have unlikely modified everything that needs to be
modified).
> 
> I don't need a proper review, just your opinion about the general idea.

How will this be used? Is it possible to just name OnDisplayBoundsChanged to
OnDisplayMetricsChanged instead?

[mlamouri (slow - plz ping), 2014-04-30 16:58:36]

On 2014/04/29 17:19:49, oshima wrote:
> On 2014/04/29 15:54:13, Mounir Lamouri wrote:
> > oshima@, does that sound reasonable to you? There are a lot of tests to fix
> and
> > code to update (I have unlikely modified everything that needs to be
> modified).
> > 
> > I don't need a proper review, just your opinion about the general idea.
> 
> How will this be used? Is it possible to just name OnDisplayBoundsChanged to
> OnDisplayMetricsChanged instead?

We could, but that would require a few things:
1. we might need a "old_display" and "new_display" in the method to let the
consumer check what has actually changed;
2. all the consumers of OnDisplayBoundsChanged are assuming that the bounds have
changed. If we change the meaning, we might need to go one by one and maybe add
|if (old_display.bounds() != new_display.bounds()) {|. Sounds like a lot of
repetitive work with a big chance of human failure.

If you think it is worth it, I guess I can go ahead.

An alternative would be to add a OnDisplayMetricsChanged() and keep
OnDispalyBoundsChanged() and try to move things over to
OnDisplayMetricsChanged() with time.

[oshima, 2014-05-01 17:29:56]

On 2014/04/30 16:58:36, Mounir Lamouri wrote:
> On 2014/04/29 17:19:49, oshima wrote:
> > On 2014/04/29 15:54:13, Mounir Lamouri wrote:
> > > oshima@, does that sound reasonable to you? There are a lot of tests to
fix
> > and
> > > code to update (I have unlikely modified everything that needs to be
> > modified).
> > > 
> > > I don't need a proper review, just your opinion about the general idea.
> > 
> > How will this be used? Is it possible to just name OnDisplayBoundsChanged to
> > OnDisplayMetricsChanged instead?
> 
> We could, but that would require a few things:
> 1. we might need a "old_display" and "new_display" in the method to let the
> consumer check what has actually changed;
> 2. all the consumers of OnDisplayBoundsChanged are assuming that the bounds
have
> changed. If we change the meaning, we might need to go one by one and maybe
add
> |if (old_display.bounds() != new_display.bounds()) {|. Sounds like a lot of
> repetitive work with a big chance of human failure.

The code must be able to handle it. What is the goal of this change by the way?
(Please file a bug if there is a specific use case)

> 
> If you think it is worth it, I guess I can go ahead.
> 
> An alternative would be to add a OnDisplayMetricsChanged() and keep
> OnDispalyBoundsChanged() and try to move things over to
> OnDisplayMetricsChanged() with time.

My concern is that these events are not mutually exclusive. That is, when
rotation changes,
its bounds also changes (in most case).

I think it's better to have one and then add a enum to tell what was changed.

enum MetricsType {
  DISPLAY_METRICS_NONE = 0,
  DISPLAY_METRICS_BOUNDS = 1 << 0,
  DISPLAY_METRICS_ROTATION = 1 << 1,
};

OnDisplayMetricsChanaged(gfx::Display display, MetricsType changed_metrics);

[mlamouri (slow - plz ping), 2014-05-01 17:40:17]

On 2014/05/01 17:29:56, oshima wrote:
> On 2014/04/30 16:58:36, Mounir Lamouri wrote:
> > On 2014/04/29 17:19:49, oshima wrote:
> > > On 2014/04/29 15:54:13, Mounir Lamouri wrote:
> > > > oshima@, does that sound reasonable to you? There are a lot of tests to
> fix
> > > and
> > > > code to update (I have unlikely modified everything that needs to be
> > > modified).
> > > > 
> > > > I don't need a proper review, just your opinion about the general idea.
> > > 
> > > How will this be used? Is it possible to just name OnDisplayBoundsChanged
to
> > > OnDisplayMetricsChanged instead?
> > 
> > We could, but that would require a few things:
> > 1. we might need a "old_display" and "new_display" in the method to let the
> > consumer check what has actually changed;
> > 2. all the consumers of OnDisplayBoundsChanged are assuming that the bounds
> have
> > changed. If we change the meaning, we might need to go one by one and maybe
> add
> > |if (old_display.bounds() != new_display.bounds()) {|. Sounds like a lot of
> > repetitive work with a big chance of human failure.
> 
> The code must be able to handle it. What is the goal of this change by the
way?
> (Please file a bug if there is a specific use case)

http://crbug.com/162827

> > If you think it is worth it, I guess I can go ahead.
> > 
> > An alternative would be to add a OnDisplayMetricsChanged() and keep
> > OnDispalyBoundsChanged() and try to move things over to
> > OnDisplayMetricsChanged() with time.
> 
> My concern is that these events are not mutually exclusive. That is, when
> rotation changes,
> its bounds also changes (in most case).

Not for 180 degrees changes obviously.

> I think it's better to have one and then add a enum to tell what was changed.
> 
> enum MetricsType {
>   DISPLAY_METRICS_NONE = 0,
>   DISPLAY_METRICS_BOUNDS = 1 << 0,
>   DISPLAY_METRICS_ROTATION = 1 << 1,
> };
> 
> OnDisplayMetricsChanaged(gfx::Display display, MetricsType changed_metrics);

That sounds good to me. I will update the CL accordingly.

[oshima, 2014-05-01 17:51:29]

On 2014/05/01 17:40:17, Mounir Lamouri wrote:
> On 2014/05/01 17:29:56, oshima wrote:
> > On 2014/04/30 16:58:36, Mounir Lamouri wrote:
> > > On 2014/04/29 17:19:49, oshima wrote:
> > > > On 2014/04/29 15:54:13, Mounir Lamouri wrote:
> > > > > oshima@, does that sound reasonable to you? There are a lot of tests
to
> > fix
> > > > and
> > > > > code to update (I have unlikely modified everything that needs to be
> > > > modified).
> > > > > 
> > > > > I don't need a proper review, just your opinion about the general
idea.
> > > > 
> > > > How will this be used? Is it possible to just name
OnDisplayBoundsChanged
> to
> > > > OnDisplayMetricsChanged instead?
> > > 
> > > We could, but that would require a few things:
> > > 1. we might need a "old_display" and "new_display" in the method to let
the
> > > consumer check what has actually changed;
> > > 2. all the consumers of OnDisplayBoundsChanged are assuming that the
bounds
> > have
> > > changed. If we change the meaning, we might need to go one by one and
maybe
> > add
> > > |if (old_display.bounds() != new_display.bounds()) {|. Sounds like a lot
of
> > > repetitive work with a big chance of human failure.
> > 
> > The code must be able to handle it. What is the goal of this change by the
> way?
> > (Please file a bug if there is a specific use case)
> 
> http://crbug.com/162827
> 
> > > If you think it is worth it, I guess I can go ahead.
> > > 
> > > An alternative would be to add a OnDisplayMetricsChanged() and keep
> > > OnDispalyBoundsChanged() and try to move things over to
> > > OnDisplayMetricsChanged() with time.
> > 
> > My concern is that these events are not mutually exclusive. That is, when
> > rotation changes,
> > its bounds also changes (in most case).
> 
> Not for 180 degrees changes obviously.

Understand (that's why I said in most case). And I probably didn't mention my
concern properly.
If there are two methods, we need to call them one by one and require the order
definition.

> 
> > I think it's better to have one and then add a enum to tell what was
changed.
> > 
> > enum MetricsType {
> >   DISPLAY_METRICS_NONE = 0,
> >   DISPLAY_METRICS_BOUNDS = 1 << 0,
> >   DISPLAY_METRICS_ROTATION = 1 << 1,
> > };
> > 
> > OnDisplayMetricsChanaged(gfx::Display display, MetricsType changed_metrics);
> 
> That sounds good to me. I will update the CL accordingly.

[mlamouri (slow - plz ping), 2014-05-07 18:08:17]

Oshima, PTAL :)

[mlamouri (slow - plz ping), 2014-05-08 13:21:28]

erg, could you review the changes in:
  ui/views/widget/desktop_aura/*

stevenjb, could you review the changes in:
  chrome/browser/ui/ash/launcher/*
  chrome/browser/ui/webui/options/chromeos/*
  ui/message_center/views/*

jochen, could you review the changes in:
  chrome/browser/extensions/*
  content/browser/renderer_host/*

oshima, could you review the changes in:
  ash/*
  ui/gfx/display_observer.h

Thanks all :)

[oshima, 2014-05-08 18:06:49]

thank you for working on this.

https://codereview.chromium.org/259253002/diff/70001/ash/display/display_cont...
File ash/display/display_controller.cc (right):

https://codereview.chromium.org/259253002/diff/70001/ash/display/display_cont...
ash/display/display_controller.cc:615: if (!(metrics & DISPLAY_METRICS_BOUNDS))
we need to update this for rotation change as well.

https://codereview.chromium.org/259253002/diff/70001/ash/display/display_mana...
File ash/display/display_manager.cc (right):

https://codereview.chromium.org/259253002/diff/70001/ash/display/display_mana...
ash/display/display_manager.cc:813:
gfx::DisplayObserver::DISPLAY_METRICS_ROTATION;
are you going to change this to notify the correct metrics change?

https://codereview.chromium.org/259253002/diff/70001/ash/wm/maximize_mode/max...
File ash/wm/maximize_mode/maximize_mode_window_manager.h (right):

https://codereview.chromium.org/259253002/diff/70001/ash/wm/maximize_mode/max...
ash/wm/maximize_mode/maximize_mode_window_manager.h:49: // aura::DisplayObserver
overrides:
could you please update this to gfx:: ?

https://codereview.chromium.org/259253002/diff/70001/ui/gfx/display_observer.h
File ui/gfx/display_observer.h (right):

https://codereview.chromium.org/259253002/diff/70001/ui/gfx/display_observer....
ui/gfx/display_observer.h:18: enum MetricsType {
I believe the chrome style recommends EnumName -> ENUM_NAME_XXX style.
Just DisplayMetrics would be fine.

https://codereview.chromium.org/259253002/diff/70001/ui/message_center/views/...
File ui/message_center/views/toast_contents_view.cc (right):

https://codereview.chromium.org/259253002/diff/70001/ui/message_center/views/...
ui/message_center/views/toast_contents_view.cc:241: int metrics =
gfx::DisplayObserver::DISPLAY_METRICS_BOUNDS |
const

[mlamouri (slow - plz ping), 2014-05-09 16:11:38]

PTAL

https://codereview.chromium.org/259253002/diff/70001/ash/display/display_cont...
File ash/display/display_controller.cc (right):

https://codereview.chromium.org/259253002/diff/70001/ash/display/display_cont...
ash/display/display_controller.cc:615: if (!(metrics & DISPLAY_METRICS_BOUNDS))
On 2014/05/08 18:06:50, oshima wrote:
> we need to update this for rotation change as well.

Done.

https://codereview.chromium.org/259253002/diff/70001/ash/display/display_mana...
File ash/display/display_manager.cc (right):

https://codereview.chromium.org/259253002/diff/70001/ash/display/display_mana...
ash/display/display_manager.cc:813:
gfx::DisplayObserver::DISPLAY_METRICS_ROTATION;
On 2014/05/08 18:06:50, oshima wrote:
> are you going to change this to notify the correct metrics change?

Done. Understanding how the Display objects are handled in a multi display
scenario wasn't easy. I'm glad this code is tested ;)

https://codereview.chromium.org/259253002/diff/70001/ash/wm/maximize_mode/max...
File ash/wm/maximize_mode/maximize_mode_window_manager.h (right):

https://codereview.chromium.org/259253002/diff/70001/ash/wm/maximize_mode/max...
ash/wm/maximize_mode/maximize_mode_window_manager.h:49: // aura::DisplayObserver
overrides:
On 2014/05/08 18:06:50, oshima wrote:
> could you please update this to gfx:: ?

Done.

https://codereview.chromium.org/259253002/diff/70001/ui/gfx/display_observer.h
File ui/gfx/display_observer.h (right):

https://codereview.chromium.org/259253002/diff/70001/ui/gfx/display_observer....
ui/gfx/display_observer.h:18: enum MetricsType {
On 2014/05/08 18:06:50, oshima wrote:
> I believe the chrome style recommends EnumName -> ENUM_NAME_XXX style.
> Just DisplayMetrics would be fine.

Done.

https://codereview.chromium.org/259253002/diff/70001/ui/message_center/views/...
File ui/message_center/views/toast_contents_view.cc (right):

https://codereview.chromium.org/259253002/diff/70001/ui/message_center/views/...
ui/message_center/views/toast_contents_view.cc:241: int metrics =
gfx::DisplayObserver::DISPLAY_METRICS_BOUNDS |
On 2014/05/08 18:06:50, oshima wrote:
> const 

Done.

https://codereview.chromium.org/259253002/diff/70001/ui/message_center/views/...
ui/message_center/views/toast_contents_view.cc:241: int metrics =
gfx::DisplayObserver::DISPLAY_METRICS_BOUNDS |
On 2014/05/08 18:06:50, oshima wrote:
> const 

Done.

[stevenjb, 2014-05-09 18:51:32]

ash/system/ and ui/message_center lgtm

https://codereview.chromium.org/259253002/diff/80001/ui/message_center/views/...
File ui/message_center/views/toast_contents_view.cc (right):

https://codereview.chromium.org/259253002/diff/80001/ui/message_center/views/...
ui/message_center/views/toast_contents_view.cc:245:
static_cast<gfx::DisplayObserver::DisplayMetrics>(metrics));
nit: alignment of this is confusing, maybe add a break before gfx::Screen and
align args to OnDisplayMetricsChanged.

https://codereview.chromium.org/259253002/diff/80001/ui/message_center/views/...
ui/message_center/views/toast_contents_view.cc:259:
gfx::DisplayObserver::DISPLAY_METRICS_WORK_AREA);
ditto

[mlamouri (slow - plz ping), 2014-05-12 09:20:16]

oshima@, erg@ and jochen@, could you guys have a look at this patch too? Thanks
:)

https://codereview.chromium.org/259253002/diff/80001/ui/message_center/views/...
File ui/message_center/views/toast_contents_view.cc (right):

https://codereview.chromium.org/259253002/diff/80001/ui/message_center/views/...
ui/message_center/views/toast_contents_view.cc:245:
static_cast<gfx::DisplayObserver::DisplayMetrics>(metrics));
On 2014/05/09 18:51:33, stevenjb wrote:
> nit: alignment of this is confusing, maybe add a break before gfx::Screen and
> align args to OnDisplayMetricsChanged.

Sadly, doing that was creating a 83 characters line. I had to add `using
gfx::Screen` to keep this readable.

https://codereview.chromium.org/259253002/diff/80001/ui/message_center/views/...
ui/message_center/views/toast_contents_view.cc:259:
gfx::DisplayObserver::DISPLAY_METRICS_WORK_AREA);
On 2014/05/09 18:51:33, stevenjb wrote:
> ditto

Done.

[Elliot Glaysher, 2014-05-12 17:47:10]

https://codereview.chromium.org/259253002/diff/100001/ui/gfx/display_observer.h
File ui/gfx/display_observer.h (right):

https://codereview.chromium.org/259253002/diff/100001/ui/gfx/display_observer...
ui/gfx/display_observer.h:35: const Display& display, DisplayMetrics
changed_metrics) = 0;
Bitfields should be ints; enums imply mutual exclusivity.

https://codereview.chromium.org/259253002/diff/100001/ui/views/widget/desktop...
File ui/views/widget/desktop_aura/desktop_screen_x11.cc (right):

https://codereview.chromium.org/259253002/diff/100001/ui/views/widget/desktop...
ui/views/widget/desktop_aura/desktop_screen_x11.cc:160:
static_cast<gfx::DisplayObserver::DisplayMetrics>(metrics)));
That you have to make this cast should be a sign that the argument type is
wrong.

[oshima, 2014-05-12 19:58:13]

https://codereview.chromium.org/259253002/diff/100001/ui/gfx/display_observer.h
File ui/gfx/display_observer.h (right):

https://codereview.chromium.org/259253002/diff/100001/ui/gfx/display_observer...
ui/gfx/display_observer.h:35: const Display& display, DisplayMetrics
changed_metrics) = 0;
On 2014/05/12 17:47:11, Elliot Glaysher wrote:
> Bitfields should be ints; enums imply mutual exclusivity.

Using enum for bitfield isn't uncommon (can be found gfx::Canvas, base::File and
many other places) and also I couldn't find this in the style guide. 

What's wrong is the argument type. It should be uint32 instead of
DisplayMetrics.

[jochen (gone - plz use gerrit), 2014-05-14 09:05:42]

https://codereview.chromium.org/259253002/diff/100001/chrome/browser/extensio...
File chrome/browser/extensions/api/system_info/system_info_api.cc (right):

https://codereview.chromium.org/259253002/diff/100001/chrome/browser/extensio...
chrome/browser/extensions/api/system_info/system_info_api.cc:72:
DisplayObserver::DisplayMetrics metrics) OVERRIDE;
please clang-format

https://codereview.chromium.org/259253002/diff/100001/chrome/browser/extensio...
chrome/browser/extensions/api/system_info/system_info_api.cc:195: const
gfx::Display&, DisplayObserver::DisplayMetrics) {
please do not omit parameter names

https://codereview.chromium.org/259253002/diff/100001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

https://codereview.chromium.org/259253002/diff/100001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_view_aura.cc:1543: const
gfx::Display& display, DisplayObserver::DisplayMetrics) {
please don't omit parameter names

https://codereview.chromium.org/259253002/diff/100001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_view_aura.h (right):

https://codereview.chromium.org/259253002/diff/100001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_view_aura.h:266:
DisplayObserver::DisplayMetrics metrics) OVERRIDE;
please clang-format

[mlamouri (slow - plz ping), 2014-05-14 11:40:17]

I applied the comments from jochen@, oshima@ and erg@. Could you guys PTAL?

[jochen (gone - plz use gerrit), 2014-05-14 12:33:45]

My bits lgtm when oshima and erg are happy

[oshima, 2014-05-14 15:53:33]

https://codereview.chromium.org/259253002/diff/140001/ash/display/display_con...
File ash/display/display_controller.h (right):

https://codereview.chromium.org/259253002/diff/140001/ash/display/display_con...
ash/display/display_controller.h:153: DisplayObserver::DisplayMetrics metrics)
OVERRIDE;
this should be uint32. I probably misguided when we discussed. sorry about that.

https://codereview.chromium.org/259253002/diff/140001/ash/display/display_man...
File ash/display/display_manager.cc (right):

https://codereview.chromium.org/259253002/diff/140001/ash/display/display_man...
ash/display/display_manager.cc:719: gfx::DisplayObserver::DisplayMetrics metrics
=
uint32

https://codereview.chromium.org/259253002/diff/140001/ash/display/display_man...
ash/display/display_manager.cc:791: gfx::DisplayObserver::DisplayMetrics metrics
=
ditto

[mlamouri (slow - plz ping), 2014-05-15 06:56:36]

oshima, it is not clear to me why you want me to use uint32_t instead of
gfx::DisplayObserver::DisplayMetrics. gfx::DisplayObserver::DisplayMetrics is
currently defined as uint8_t (and DisplayMetric [no s] is the enum). Using a
typedef here allows us to keep the size of the bitfield hidden so we can change
it easily and make the code nicer to read IMO. Is this pattern forbidden by the
Chrome coding style for some reason?

[mlamouri (slow - plz ping), 2014-05-19 12:44:07]

On 2014/05/15 06:56:36, Mounir Lamouri wrote:
> oshima, it is not clear to me why you want me to use uint32_t instead of
> gfx::DisplayObserver::DisplayMetrics. gfx::DisplayObserver::DisplayMetrics is
> currently defined as uint8_t (and DisplayMetric [no s] is the enum). Using a
> typedef here allows us to keep the size of the bitfield hidden so we can
change
> it easily and make the code nicer to read IMO. Is this pattern forbidden by
the
> Chrome coding style for some reason?

oshima@, could you have a look at my previous comment? I would like to know if
there is anything I need to change in order to get this landed. Thanks :)

[oshima, 2014-05-20 01:03:01]

sorry for delay.

https://codereview.chromium.org/259253002/diff/140001/ui/gfx/display_observer.h
File ui/gfx/display_observer.h (right):

https://codereview.chromium.org/259253002/diff/140001/ui/gfx/display_observer...
ui/gfx/display_observer.h:25: DISPLAY_METRICS_ROTATION = 1 << 3,
DISPLAY_METRIC_ (be consistent with enum type)

https://codereview.chromium.org/259253002/diff/140001/ui/gfx/display_observer...
ui/gfx/display_observer.h:27: typedef uint8_t DisplayMetrics;
My preference is just to use uint32. unit32 is more common for bitmaps, and they
are so similar that people may mix up DisplayMetric and DisplayMetrics

[mlamouri (slow - plz ping), 2014-05-20 12:52:57]

I applied your comments oshima, could you PTAL?

https://codereview.chromium.org/259253002/diff/140001/ui/gfx/display_observer.h
File ui/gfx/display_observer.h (right):

https://codereview.chromium.org/259253002/diff/140001/ui/gfx/display_observer...
ui/gfx/display_observer.h:25: DISPLAY_METRICS_ROTATION = 1 << 3,
On 2014/05/20 01:03:02, oshima wrote:
> DISPLAY_METRIC_ (be consistent with enum type)

Done.

https://codereview.chromium.org/259253002/diff/140001/ui/gfx/display_observer...
ui/gfx/display_observer.h:27: typedef uint8_t DisplayMetrics;
On 2014/05/20 01:03:02, oshima wrote:
> My preference is just to use uint32. unit32 is more common for bitmaps, and
they
> are so similar that people may mix up DisplayMetric and DisplayMetrics
> 

I changed this but for the record, I would have preferred uint8_t because the
underlying type shouldn't matter here. Not worth dragging the review more though
because this patch is getting bit rotten quite quickly ;)

[mlamouri (slow - plz ping), 2014-05-20 12:56:00]

tommi@, could you review the changes in:
  media/video/capture/linux/video_capture_device_chromeos.cc

[oshima, 2014-05-20 15:13:28]

https://codereview.chromium.org/259253002/diff/160001/ui/gfx/display_observer.h
File ui/gfx/display_observer.h (right):

https://codereview.chromium.org/259253002/diff/160001/ui/gfx/display_observer...
ui/gfx/display_observer.h:27: typedef uint32_t DisplayMetrics;
Sorry if it wasn't clear. My point was that we should use just uint32_t instead
of typedef.

[mlamouri (slow - plz ping), 2014-05-20 15:54:32]

On 2014/05/20 15:13:28, oshima wrote:
>
https://codereview.chromium.org/259253002/diff/160001/ui/gfx/display_observer.h
> File ui/gfx/display_observer.h (right):
> 
>
https://codereview.chromium.org/259253002/diff/160001/ui/gfx/display_observer...
> ui/gfx/display_observer.h:27: typedef uint32_t DisplayMetrics;
> Sorry if it wasn't clear. My point was that we should use just uint32_t
instead
> of typedef.

I have updated the cl to use uint32_t. PTAL.

[oshima, 2014-05-20 16:19:57]

lgtm

[mlamouri (slow - plz ping), 2014-05-20 16:24:39]

On 2014/05/20 16:19:57, oshima wrote:
> lgtm

Thanks! :)

erg@, could you PTAL at the changes in x11 files?

[tommi (sloooow) - chröme, 2014-05-20 16:26:38]

Lgtm for video_capture_device_chromeos.cc

[Elliot Glaysher, 2014-05-20 17:45:26]

lgtm

[mlamouri (slow - plz ping), 2014-05-20 17:45:46]

The CQ bit was checked by mlamouri@chromium.org

[commit-bot: I haz the power, 2014-05-20 17:46:19]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/mlamouri@chromium.org/259253002/180001

[commit-bot: I haz the power, 2014-05-20 21:52:39]

Change committed as 271768

[Nicolas Zea, 2014-05-20 23:15:31]

A revert of this CL has been created in
https://codereview.chromium.org/294963004/ by zea@chromium.org.

The reason for reverting is: Breaks DesktopScreenX11Test.RemoveMonitorOnRight
and AddMonitorToTheRight on Linux Tests

http://build.chromium.org/p/chromium.linux/buildstatus?builder=Linux%20Tests&....

[mlamouri (slow - plz ping), 2014-05-21 11:07:34]

The CQ bit was checked by mlamouri@chromium.org

[commit-bot: I haz the power, 2014-05-21 11:09:43]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/mlamouri@chromium.org/259253002/200001

[commit-bot: I haz the power, 2014-05-22 01:26:06]

Change committed as 272040