Allow javascript change the virtual keyboard window size and position freely in FLOATING mode

Allow javascript change the virtual keyboard window size and position freely in FLOATING mode

This CL includes the following changes:
1. The virtual keyboard container window is no longer automatically set to full screen size.
Instead, it will be set to the same size as the virtual keyboard window and will be positioned
where that window was positioned. This is to allow window.moveTo to move the VK window
correctly.
2. VK window and VK container is no longer always full width. In FLOATING mode,
window.resizeTo can resize the VK window to specified size.
3. Added one test for FLOATING mode and other tests fixes

BUG=466702
Committed: https://crrev.com/a0a5780fdc75676746d9e754424834a1812357eb
Cr-Commit-Position: refs/heads/master@{#324253}

[bshe, 2015-03-12 19:35:51]

bshe@chromium.org changed reviewers:
+ sadrul@chromium.org, shuchen@chromium.org

[bshe, 2015-03-12 19:35:52]

Hey Sadrul and Shu.

Do you guys mind to take a look at this CL?
A little bit background in case you dont know:
We plan to add floating virtual keyboard mode, which allows user to resize or
drag the virtual keyboard window, to ChromeOS. This CL allows user to resize and
move the virtual keyboard window though javascript in FLOATING mode.

Any suggestion is welcome! Thanks!

[bshe, 2015-03-13 15:46:53]

On 2015/03/12 19:35:52, bshe wrote:
> Hey Sadrul and Shu.
> 
> Do you guys mind to take a look at this CL?
> A little bit background in case you dont know:
> We plan to add floating virtual keyboard mode, which allows user to resize or
> drag the virtual keyboard window, to ChromeOS. This CL allows user to resize
and
> move the virtual keyboard window though javascript in FLOATING mode.
> 
> Any suggestion is welcome! Thanks!

Sorry, please hold review for this CL. I just found a problem. Will ping this
thread again when I fixed it. Thanks

[bshe, 2015-03-17 15:57:49]

On 2015/03/13 15:46:53, bshe wrote:
> On 2015/03/12 19:35:52, bshe wrote:
> > Hey Sadrul and Shu.
> > 
> > Do you guys mind to take a look at this CL?
> > A little bit background in case you dont know:
> > We plan to add floating virtual keyboard mode, which allows user to resize
or
> > drag the virtual keyboard window, to ChromeOS. This CL allows user to resize
> and
> > move the virtual keyboard window though javascript in FLOATING mode.
> > 
> > Any suggestion is welcome! Thanks!
> 
> Sorry, please hold review for this CL. I just found a problem. Will ping this
> thread again when I fixed it. Thanks


Hey. I think this is ready for review now.

I have changed the way how keyboard container works in this CL. This is because
we
want to support window.moveTo for the virtual keyboard window. The keyboard
container
used to be a full screen window. Now it is the same size as the keyboard window
and positioned
where keyboard window should be.
I tested my patch on my glimmer and everything looks good so far and
window.moveTo works
as expected.

[Shu Chen, 2015-03-18 03:58:09]

lgtm

I'm not familiar enough with the code base to check the logic changes.
Just had a rough look and didn't find things cause my concern.

[bshe, 2015-03-18 21:20:25]

On 2015/03/18 03:58:09, Shu Chen wrote:
> lgtm
> 
> I'm not familiar enough with the code base to check the logic changes.
> Just had a rough look and didn't find things cause my concern.

thanks Shu!
Sadrul, do you mind to take a look? thanks

[sadrul, 2015-03-20 17:32:17]

I feel like we are actually going to lose test-coverage because of the changes
in the tests. Would it be possible to make the tests better, and not just use
the root-window bounds so the tests pass?

Since the keyboard-window can now have any size, do we still actually need
KeyboardBoundsFromWindowBounds()?

https://codereview.chromium.org/1008453002/diff/100001/ash/root_window_contro...
File ash/root_window_controller_unittest.cc (right):

https://codereview.chromium.org/1008453002/diff/100001/ash/root_window_contro...
ash/root_window_controller_unittest.cc:842:
text_input_client.visible_rect().height());
Not sure what this test is checking anymore. Can you explain?

https://codereview.chromium.org/1008453002/diff/100001/ash/root_window_contro...
ash/root_window_controller_unittest.cc:959: EXPECT_EQ("0,800 600x0",
keyboard_container->bounds().ToString());
Why the change in this test?

https://codereview.chromium.org/1008453002/diff/100001/ui/keyboard/keyboard_l...
File ui/keyboard/keyboard_layout_manager.cc (right):

https://codereview.chromium.org/1008453002/diff/100001/ui/keyboard/keyboard_l...
ui/keyboard/keyboard_layout_manager.cc:36:
controller_->GetContainerWindow()->SetBounds(child->bounds());
Looks like you are setting container-bounds == keyboard-bounds. That wouldn't do
the right thing when keyboard-bounds origin is not at (0,0), right? For example,
if child-bounds == (0, 100, 500, 300), then setting the container's bounds to
(0, 100, 500, 300) would end up (assuming the container's parent is at (0,0))
moving the keyboard window at (0, 200) in the screen, and parts of the
keyboard-window will fall out of the container window.

[bshe, 2015-03-27 16:21:26]

Patchset #8 (id:140001) has been deleted

[bshe, 2015-03-27 16:21:46]

Patchset #7 (id:120001) has been deleted

[bshe, 2015-03-27 16:29:16]

PTAL. The latest patch should be more readable. And I have removed custom
event targeter pre offline discussion. The keyboard container is now the same
size as keyboard window. so it is no longer necessary.

>I feel like we are actually going to lose test-coverage because of the changes
>in the tests. Would it be possible to make the tests better, and not just use
>the root-window bounds so the tests pass?

>Since the keyboard-window can now have any size, do we still actually need
>KeyboardBoundsFromWindowBounds()?
It is still useful when keyboard is in FULL_WIDTH mode. I have changed the
function
name so it is more clear. For tests, some tests actually needs root window
bounds. We
previously use keyboard container bounds is because it is the same as root
bounds. The
new patch should be more clear.

https://codereview.chromium.org/1008453002/diff/100001/ash/root_window_contro...
File ash/root_window_controller_unittest.cc (right):

https://codereview.chromium.org/1008453002/diff/100001/ash/root_window_contro...
ash/root_window_controller_unittest.cc:842:
text_input_client.visible_rect().height());
On 2015/03/20 17:32:16, sadrul wrote:
> Not sure what this test is checking anymore. Can you explain?

I think it is still testing the visible_rect of text_input_client is not
occluded by keyboard window in FULL_WIDTH mode. More specifically, I think it
tests EnsureCaretInRect is called with expected bounds:
https://code.google.com/p/chromium/codesearch/#chromium/src/ui/keyboard/keybo...

https://codereview.chromium.org/1008453002/diff/100001/ash/root_window_contro...
ash/root_window_controller_unittest.cc:959: EXPECT_EQ("0,800 600x0",
keyboard_container->bounds().ToString());
On 2015/03/20 17:32:17, sadrul wrote:
> Why the change in this test?

After a screen rotation, we want to make sure that the width of keyboard
container is the same as screen width in default(FULL_WIDTH) mode. So I changed
it in test. The default height of keyboard container is always 0 in default
mode. It is perhaps easier to read if the default height is not 0. I have
updated test.

https://codereview.chromium.org/1008453002/diff/100001/ui/keyboard/keyboard_l...
File ui/keyboard/keyboard_layout_manager.cc (right):

https://codereview.chromium.org/1008453002/diff/100001/ui/keyboard/keyboard_l...
ui/keyboard/keyboard_layout_manager.cc:36:
controller_->GetContainerWindow()->SetBounds(child->bounds());
On 2015/03/20 17:32:17, sadrul wrote:
> Looks like you are setting container-bounds == keyboard-bounds. That wouldn't
do
> the right thing when keyboard-bounds origin is not at (0,0), right? For
example,
> if child-bounds == (0, 100, 500, 300), then setting the container's bounds to
> (0, 100, 500, 300) would end up (assuming the container's parent is at (0,0))
> moving the keyboard window at (0, 200) in the screen, and parts of the
> keyboard-window will fall out of the container window.

Discussed offline. The child bounds is used by container window first. After we
positioned container window to where the child suppose to be positioned, we then
set child bounds to (0, 0, width, height) in container window (see line 23 in
this file).  So in the above example, the keyboard window is still at (0, 100,
500, 300). Add a SetChildDirect call to make code easier to read.

[bshe, 2015-03-31 12:26:25]

On 2015/03/27 16:29:16, bshe wrote:
> PTAL. The latest patch should be more readable. And I have removed custom
> event targeter pre offline discussion. The keyboard container is now the same
> size as keyboard window. so it is no longer necessary.
> 
> >I feel like we are actually going to lose test-coverage because of the
changes
> >in the tests. Would it be possible to make the tests better, and not just use
> >the root-window bounds so the tests pass?
> 
> >Since the keyboard-window can now have any size, do we still actually need
> >KeyboardBoundsFromWindowBounds()?
> It is still useful when keyboard is in FULL_WIDTH mode. I have changed the
> function
> name so it is more clear. For tests, some tests actually needs root window
> bounds. We
> previously use keyboard container bounds is because it is the same as root
> bounds. The
> new patch should be more clear.
> 
>
https://codereview.chromium.org/1008453002/diff/100001/ash/root_window_contro...
> File ash/root_window_controller_unittest.cc (right):
> 
>
https://codereview.chromium.org/1008453002/diff/100001/ash/root_window_contro...
> ash/root_window_controller_unittest.cc:842:
> text_input_client.visible_rect().height());
> On 2015/03/20 17:32:16, sadrul wrote:
> > Not sure what this test is checking anymore. Can you explain?
> 
> I think it is still testing the visible_rect of text_input_client is not
> occluded by keyboard window in FULL_WIDTH mode. More specifically, I think it
> tests EnsureCaretInRect is called with expected bounds:
>
https://code.google.com/p/chromium/codesearch/#chromium/src/ui/keyboard/keybo...
> 
>
https://codereview.chromium.org/1008453002/diff/100001/ash/root_window_contro...
> ash/root_window_controller_unittest.cc:959: EXPECT_EQ("0,800 600x0",
> keyboard_container->bounds().ToString());
> On 2015/03/20 17:32:17, sadrul wrote:
> > Why the change in this test?
> 
> After a screen rotation, we want to make sure that the width of keyboard
> container is the same as screen width in default(FULL_WIDTH) mode. So I
changed
> it in test. The default height of keyboard container is always 0 in default
> mode. It is perhaps easier to read if the default height is not 0. I have
> updated test.
> 
>
https://codereview.chromium.org/1008453002/diff/100001/ui/keyboard/keyboard_l...
> File ui/keyboard/keyboard_layout_manager.cc (right):
> 
>
https://codereview.chromium.org/1008453002/diff/100001/ui/keyboard/keyboard_l...
> ui/keyboard/keyboard_layout_manager.cc:36:
> controller_->GetContainerWindow()->SetBounds(child->bounds());
> On 2015/03/20 17:32:17, sadrul wrote:
> > Looks like you are setting container-bounds == keyboard-bounds. That
wouldn't
> do
> > the right thing when keyboard-bounds origin is not at (0,0), right? For
> example,
> > if child-bounds == (0, 100, 500, 300), then setting the container's bounds
to
> > (0, 100, 500, 300) would end up (assuming the container's parent is at
(0,0))
> > moving the keyboard window at (0, 200) in the screen, and parts of the
> > keyboard-window will fall out of the container window.
> 
> Discussed offline. The child bounds is used by container window first. After
we
> positioned container window to where the child suppose to be positioned, we
then
> set child bounds to (0, 0, width, height) in container window (see line 23 in
> this file).  So in the above example, the keyboard window is still at (0, 100,
> 500, 300). Add a SetChildDirect call to make code easier to read.

friendly ping?

[sadrul, 2015-04-01 06:43:49]

https://codereview.chromium.org/1008453002/diff/180001/ash/wm/virtual_keyboar...
File ash/wm/virtual_keyboard_container_layout_manager.cc (right):

https://codereview.chromium.org/1008453002/diff/180001/ash/wm/virtual_keyboar...
ash/wm/virtual_keyboard_container_layout_manager.cc:38: }  // namespace ash
Is this layout-manager necessary at all? KeyboardController is already a
WindowObserver. Should it just observe the root-window, and update the bounds
when the RW's bounds changes?

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_c...
File ui/keyboard/keyboard_controller.cc (right):

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_c...
ui/keyboard/keyboard_controller.cc:57: explicit KeyboardWindowDelegate() {}
Don't need explicit

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_c...
File ui/keyboard/keyboard_controller.h (right):

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_c...
ui/keyboard/keyboard_controller.h:95: KeyboardMode keyboard_mode() { return
keyboard_mode_; }
KeyboardMode keyboard_mode() const { return ... }

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_l...
File ui/keyboard/keyboard_layout_manager.cc (right):

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_l...
ui/keyboard/keyboard_layout_manager.cc:24: container_bounds.height()));
gfx::Rect(container_bounds.size())

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_l...
ui/keyboard/keyboard_layout_manager.cc:38: child->bounds().height()));
ditto

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_l...
ui/keyboard/keyboard_layout_manager.cc:50: gfx::Rect old_bounds =
controller_->GetContainerWindow()->bounds();
const &

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_l...
ui/keyboard/keyboard_layout_manager.cc:53: gfx::Rect window_bounds =
const &

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_l...
ui/keyboard/keyboard_layout_manager.cc:73: new_bounds.height()));
gfx::Rect(new_bounds.size())

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_u...
File ui/keyboard/keyboard_util.cc (right):

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_u...
ui/keyboard/keyboard_util.cc:70: 0);
This doesn't seem to be useful. If the height is zero, then it doesn't really
matter what the origin or the width is, right? For the keyboard to be usable,
the bounds will need to be reset anyway? So do we actually need to call
DefaultKeyboardBoundsFromRootBounds() and then use the returned value to set the
bounds on the keyboard window?

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_u...
ui/keyboard/keyboard_util.cc:79: keyboard_height);
This only ever seems to be used in tests? Is that the case? Can this move into a
test-only target? (see the various *_test_support targets)

[bshe, 2015-04-01 19:02:41]

Patchset #9 (id:200001) has been deleted

[bshe, 2015-04-01 20:41:01]

Patchset #9 (id:220001) has been deleted

[bshe, 2015-04-01 20:41:34]

Thanks for excellent review! PTAL

https://codereview.chromium.org/1008453002/diff/180001/ash/wm/virtual_keyboar...
File ash/wm/virtual_keyboard_container_layout_manager.cc (right):

https://codereview.chromium.org/1008453002/diff/180001/ash/wm/virtual_keyboar...
ash/wm/virtual_keyboard_container_layout_manager.cc:38: }  // namespace ash
On 2015/04/01 06:43:48, sadrul wrote:
> Is this layout-manager necessary at all? KeyboardController is already a
> WindowObserver. Should it just observe the root-window, and update the bounds
> when the RW's bounds changes?

Looks like we dont need it. I removed the layout manager and used
KeyboardController to obseve VirtualKeyboardContainerParent window. It correctly
update the bounds when RW bounds changed.

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_c...
File ui/keyboard/keyboard_controller.cc (right):

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_c...
ui/keyboard/keyboard_controller.cc:57: explicit KeyboardWindowDelegate() {}
On 2015/04/01 06:43:48, sadrul wrote:
> Don't need explicit

Done.

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_c...
File ui/keyboard/keyboard_controller.h (right):

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_c...
ui/keyboard/keyboard_controller.h:95: KeyboardMode keyboard_mode() { return
keyboard_mode_; }
On 2015/04/01 06:43:49, sadrul wrote:
> KeyboardMode keyboard_mode() const { return ... }

Done.

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_l...
File ui/keyboard/keyboard_layout_manager.cc (right):

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_l...
ui/keyboard/keyboard_layout_manager.cc:24: container_bounds.height()));
On 2015/04/01 06:43:49, sadrul wrote:
> gfx::Rect(container_bounds.size())

Done.

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_l...
ui/keyboard/keyboard_layout_manager.cc:38: child->bounds().height()));
On 2015/04/01 06:43:49, sadrul wrote:
> ditto

Done.

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_l...
ui/keyboard/keyboard_layout_manager.cc:50: gfx::Rect old_bounds =
controller_->GetContainerWindow()->bounds();
On 2015/04/01 06:43:49, sadrul wrote:
> const &

We actually want gfx::Rect here as we need to check the height at line 76 after
the bounds of container window changed at line 71. If we only keep a reference,
the old height is not cached.

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_l...
ui/keyboard/keyboard_layout_manager.cc:53: gfx::Rect window_bounds =
On 2015/04/01 06:43:49, sadrul wrote:
> const &

Done.

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_l...
ui/keyboard/keyboard_layout_manager.cc:73: new_bounds.height()));
On 2015/04/01 06:43:49, sadrul wrote:
> gfx::Rect(new_bounds.size())

Done.

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_u...
File ui/keyboard/keyboard_util.cc (right):

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_u...
ui/keyboard/keyboard_util.cc:70: 0);
On 2015/04/01 06:43:49, sadrul wrote:
> This doesn't seem to be useful. If the height is zero, then it doesn't really
> matter what the origin or the width is, right? For the keyboard to be usable,
> the bounds will need to be reset anyway? So do we actually need to call
> DefaultKeyboardBoundsFromRootBounds() and then use the returned value to set
the
> bounds on the keyboard window?

You are right. We could probably just use gfx::Rect() to replace this function.
Done.

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_u...
ui/keyboard/keyboard_util.cc:79: keyboard_height);
On 2015/04/01 06:43:49, sadrul wrote:
> This only ever seems to be used in tests? Is that the case? Can this move into
a
> test-only target? (see the various *_test_support targets)

This is used in ui/keyboard and ash/. I can probably create a new target called
keyboard_test_support in keyboard.gyp. WDYT? If this makes sense, can I do it in
a follow up CL? This CL starts to look large.

[sadrul, 2015-04-07 17:35:51]

lgtm

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_u...
File ui/keyboard/keyboard_util.cc (right):

https://codereview.chromium.org/1008453002/diff/180001/ui/keyboard/keyboard_u...
ui/keyboard/keyboard_util.cc:79: keyboard_height);
On 2015/04/01 20:41:33, bshe wrote:
> On 2015/04/01 06:43:49, sadrul wrote:
> > This only ever seems to be used in tests? Is that the case? Can this move
into
> a
> > test-only target? (see the various *_test_support targets)
> 
> This is used in ui/keyboard and ash/. I can probably create a new target
called
> keyboard_test_support in keyboard.gyp. WDYT? If this makes sense, can I do it
in
> a follow up CL? This CL starts to look large.

Yep, makes sense. Follow up CL sgtm.

https://codereview.chromium.org/1008453002/diff/260001/ash/root_window_contro...
File ash/root_window_controller.cc (right):

https://codereview.chromium.org/1008453002/diff/260001/ash/root_window_contro...
ash/root_window_controller.cc:47: //#include
"ash/wm/virtual_keyboard_container_layout_manager.h"
Remove

https://codereview.chromium.org/1008453002/diff/260001/ui/keyboard/keyboard_c...
File ui/keyboard/keyboard_controller.cc (right):

https://codereview.chromium.org/1008453002/diff/260001/ui/keyboard/keyboard_c...
ui/keyboard/keyboard_controller.cc:364: if (window->IsRootWindow()) {
early return if (!window->IsRootWindow()) instead

[bshe, 2015-04-07 18:46:14]

bshe@chromium.org changed reviewers:
+ jamescook@chromium.org, pkotwicz@chromium.org

[bshe, 2015-04-07 18:46:15]

Thanks Sadrul!

+jamescook for ash related files
+pkotwicz for ash/wm related files

Thanks!

https://codereview.chromium.org/1008453002/diff/260001/ash/root_window_contro...
File ash/root_window_controller.cc (right):

https://codereview.chromium.org/1008453002/diff/260001/ash/root_window_contro...
ash/root_window_controller.cc:47: //#include
"ash/wm/virtual_keyboard_container_layout_manager.h"
On 2015/04/07 17:35:51, sadrul wrote:
> Remove

dooh..

Done

https://codereview.chromium.org/1008453002/diff/260001/ui/keyboard/keyboard_c...
File ui/keyboard/keyboard_controller.cc (right):

https://codereview.chromium.org/1008453002/diff/260001/ui/keyboard/keyboard_c...
ui/keyboard/keyboard_controller.cc:364: if (window->IsRootWindow()) {
On 2015/04/07 17:35:51, sadrul wrote:
> early return if (!window->IsRootWindow()) instead

Done.

[pkotwicz, 2015-04-08 15:03:30]

ash/wm LGTM

[bshe, 2015-04-08 15:07:45]

bshe@chromium.org changed reviewers:
+ oshima@chromium.org
- jamescook@chromium.org

[bshe, 2015-04-08 15:07:46]

Thanks Peter!

Switching to oshima for ash related files as James is not working on ash
anymore.

[James Cook, 2015-04-08 16:38:59]

jamescook@chromium.org changed reviewers:
+ jamescook@chromium.org

[James Cook, 2015-04-08 16:39:00]

ash/ lgtm

[bshe, 2015-04-08 16:46:35]

The CQ bit was checked by bshe@chromium.org

[bshe, 2015-04-08 16:46:35]

The patchset sent to the CQ was uploaded after l-g-t-m from
shuchen@chromium.org, sadrul@chromium.org
Link to the patchset: https://codereview.chromium.org/1008453002/#ps280001
(title: "reviews")

[commit-bot: I haz the power, 2015-04-08 16:47:26]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1008453002/280001

[commit-bot: I haz the power, 2015-04-08 16:53:38]

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

[commit-bot: I haz the power, 2015-04-08 16:53:39]

Try jobs failed on following builders:
  linux_chromium_compile_dbg_32_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  ios_dbg_simulator_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...)
  ios_rel_device_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ni...)
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[bshe, 2015-04-08 17:04:05]

The CQ bit was checked by bshe@chromium.org

[bshe, 2015-04-08 17:04:06]

The patchset sent to the CQ was uploaded after l-g-t-m from sadrul@chromium.org,
shuchen@chromium.org, pkotwicz@chromium.org, jamescook@chromium.org
Link to the patchset: https://codereview.chromium.org/1008453002/#ps320001
(title: "format")

[commit-bot: I haz the power, 2015-04-08 17:04:39]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1008453002/320001

[commit-bot: I haz the power, 2015-04-08 18:21:52]

Committed patchset #13 (id:320001)

[commit-bot: I haz the power, 2015-04-08 18:22:49]

Patchset 13 (id:??) landed as
https://crrev.com/a0a5780fdc75676746d9e754424834a1812357eb
Cr-Commit-Position: refs/heads/master@{#324253}