Cros Tablet Window management - Split Screen part II

Cros Tablet Window management - Split Screen part II

Wire up the SplitViewController with the overview mode. It's a following
up CL of https://codereview.chromium.org/2960843004/.

Changes in this CL:
1. The split view mode can be initiated by dragging the window in
overview mode to the side of the screen
2. After one window is snapped to one side of the screen, all the other
overview windows will display in the other side of the screen, allowing
the user to select another window to snap. When two windows are snapped
to both sides of the screen, the overview mode will be ended.
3. The first snapped window will remain snapped until the user
explicitly exit the split view mode. All the other windows (incluing
newly created window) will be open in the other side of the screen.
Clicking/Tapping on the overview button also open the overview windows
in the other side of the screen.

Not covered in this CL:
1. The highlighted region showing where split will occur is not
   implemented in this CL.
2. The split divider is not implemented in this CL.

BUG=725683
Review-Url: https://codereview.chromium.org/2955203002
Cr-Commit-Position: refs/heads/master@{#487542}
Committed: https://chromium.googlesource.com/chromium/src/+/0c6d79c9a3a2bf404ef94220c389924541c92f0b

[xdai1, 2017-06-27 23:01:26]

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

[commit-bot: I haz the power, 2017-06-27 23:01:57]

Dry run: CQ is trying da patch.

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

[xdai1, 2017-06-27 23:45:32]

xdai@chromium.org changed reviewers:
+ oshima@chromium.org, varkha@chromium.org

[xdai1, 2017-06-27 23:45:33]

+cc sadrul@ FYI

oshima@, varkha@, this is the second part of the original CL. In this CL the
SplitViewController is wired up with OverviewWindowDragController. Also added
tests. Note that the codes are almost the same as in the original CL.  

Please help take a look at the CL, thanks!

[xdai1, 2017-06-29 16:57:15]

oshima@, varkha@, kindly ping? Could you take a look at this CL please? Thanks!

[oshima, 2017-06-29 17:46:23]

what happens if I rotate the device while dragging?

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
File ash/wm/overview/window_selector.cc (right):

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
ash/wm/overview/window_selector.cc:153: return
split_view_controller->GetSnappedWindowBoundsInScreen(root_window,
is it hard to make root_window parameter const?

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/splitview/split_...
File ash/wm/splitview/split_view_controller_unittest.cc (left):

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/splitview/split_...
ash/wm/splitview/split_view_controller_unittest.cc:107: const gfx::Rect
bounds(0, 0, 400, 400);
why this change?

[varkha, 2017-06-30 16:32:27]

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/overvie...
File ash/wm/overview/overview_window_drag_controller.cc (right):

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/overvie...
ash/wm/overview/overview_window_drag_controller.cc:57: // Updates the dragged
|item_|'s bounds accordingly.
nit: not a method declaration so 'updates' -> 'update'

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/overvie...
ash/wm/overview/overview_window_drag_controller.cc:78: else if (split_state ==
SplitViewController::LEFT_SNAPPED)
Maybe just a bit simpler:
} else {
  SnapWindow(split_state == SplitViewController::LEFT_SNAPPED ? SNAP_RIGHT
                                                              : SNAP_LEFT);
}

Or maybe even think if the two similar enums could be merged (e.g. if this class
could just use SplitViewController::*SNAP* values.

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/overvie...
ash/wm/overview/overview_window_drag_controller.cc:87: else if (snap_type_ ==
SNAP_LEFT)
Would this work:
else
  SnapWindow(snap_type_);

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/overvie...
File ash/wm/overview/overview_window_drag_controller.h (right):

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/overvie...
ash/wm/overview/overview_window_drag_controller.h:13: #include
"ui/gfx/geometry/rect.h"
nit: do you need rect.h here? Can it be moved to .cc?

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/overvie...
ash/wm/overview/overview_window_drag_controller.h:20: class SplitViewController;
nit: sort alphabetically.

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/overvie...
ash/wm/overview/overview_window_drag_controller.h:49: // Gives a previews of
where the dragged window will end up.
nit: "Gives a previews of..." -> "Shows a highlight..."

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/overvie...
ash/wm/overview/overview_window_drag_controller.h:58: // Set to true once the
bounds of |item_| changes.
nit: changes -> change

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
File ash/wm/overview/window_selector.cc (right):

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
ash/wm/overview/window_selector.cc:733: DCHECK(state ==
SplitViewController::BOTH_SNAPPED ||
nit: Isn't BOTH_SNAPPED case handled above (or you could merge those two cases
since they both just |CancelSelection| with appropriate comment)?

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
File ash/wm/overview/window_selector.h (right):

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
ash/wm/overview/window_selector.h:83: void SetBoundsForWindowGridsInScreen(const
gfx::Rect& bounds);
nit: should we forward-declare gfx::Rect above?

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
ash/wm/overview/window_selector.h:89: const gfx::Point& location_in_screen);
nit: ditto for gfx::Point - can we forward declare and move the include to .cc?

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
ash/wm/overview/window_selector.h:106: const
std::vector<std::unique_ptr<WindowGrid>>& grid_list_for_testing() {
nit: this method can be marked as const.

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
File ash/wm/overview/window_selector_item.cc (right):

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
ash/wm/overview/window_selector_item.cc:891: break;
Would it be possible to calculate proper stacking_target in a loop above (or
return if none) and just change the stacking without an additional loop?

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
File ash/wm/overview/window_selector_item.h (right):

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
ash/wm/overview/window_selector_item.h:183: // order so that the order of
windows is the same as when they entering
nit: 'they' can be dropped.

[xdai1, 2017-07-06 00:35:50]

oshima@, varkha@, I've addressed your comments. Please take another look, thanks
for the review!

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/overvie...
File ash/wm/overview/overview_window_drag_controller.cc (right):

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/overvie...
ash/wm/overview/overview_window_drag_controller.cc:57: // Updates the dragged
|item_|'s bounds accordingly.
On 2017/06/30 16:32:26, varkha (OOO on July 3) wrote:
> nit: not a method declaration so 'updates' -> 'update'

Done.

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/overvie...
ash/wm/overview/overview_window_drag_controller.cc:78: else if (split_state ==
SplitViewController::LEFT_SNAPPED)
On 2017/06/30 16:32:26, varkha (OOO on July 3) wrote:
> Maybe just a bit simpler:
> } else {
>   SnapWindow(split_state == SplitViewController::LEFT_SNAPPED ? SNAP_RIGHT
>                                                               : SNAP_LEFT);
> }
> 
> Or maybe even think if the two similar enums could be merged (e.g. if this
class
> could just use SplitViewController::*SNAP* values.

I merged OverviewWindowDragController::SnapType enum to
SplitViewController::SnapPosition enum.

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/overvie...
ash/wm/overview/overview_window_drag_controller.cc:87: else if (snap_type_ ==
SNAP_LEFT)
On 2017/06/30 16:32:26, varkha (OOO on July 3) wrote:
> Would this work:
> else
>   SnapWindow(snap_type_);

Done.

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/overvie...
File ash/wm/overview/overview_window_drag_controller.h (right):

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/overvie...
ash/wm/overview/overview_window_drag_controller.h:13: #include
"ui/gfx/geometry/rect.h"
On 2017/06/30 16:32:26, varkha (OOO on July 3) wrote:
> nit: do you need rect.h here? Can it be moved to .cc?

You're right. Removed it.

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/overvie...
ash/wm/overview/overview_window_drag_controller.h:20: class SplitViewController;
On 2017/06/30 16:32:26, varkha (OOO on July 3) wrote:
> nit: sort alphabetically.

Done.

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/overvie...
ash/wm/overview/overview_window_drag_controller.h:49: // Gives a previews of
where the dragged window will end up.
On 2017/06/30 16:32:26, varkha (OOO on July 3) wrote:
> nit: "Gives a previews of..." -> "Shows a highlight..."

Done.

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/overvie...
ash/wm/overview/overview_window_drag_controller.h:58: // Set to true once the
bounds of |item_| changes.
On 2017/06/30 16:32:26, varkha (OOO on July 3) wrote:
> nit: changes -> change

Done.

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
File ash/wm/overview/window_selector.cc (right):

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
ash/wm/overview/window_selector.cc:153: return
split_view_controller->GetSnappedWindowBoundsInScreen(root_window,
On 2017/06/29 17:46:23, oshima wrote:
> is it hard to make root_window parameter const?

The const_cast in line 589 is inevitable, either in line 589, or in
split_view_controller.cc when calculating GetDisplayWorkAreaBoundsInScreen() if
I modify this function to accept const*.

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
ash/wm/overview/window_selector.cc:733: DCHECK(state ==
SplitViewController::BOTH_SNAPPED ||
On 2017/06/30 16:32:26, varkha (OOO on July 3) wrote:
> nit: Isn't BOTH_SNAPPED case handled above (or you could merge those two cases
> since they both just |CancelSelection| with appropriate comment)?

Sorry about my mistake here. The else if (state ==
SplitViewController::BOTH_SNAPPED) in the middle is redundant. Removed it.

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
File ash/wm/overview/window_selector.h (right):

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
ash/wm/overview/window_selector.h:83: void SetBoundsForWindowGridsInScreen(const
gfx::Rect& bounds);
On 2017/06/30 16:32:26, varkha (OOO on July 3) wrote:
> nit: should we forward-declare gfx::Rect above? 

Done.

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
ash/wm/overview/window_selector.h:89: const gfx::Point& location_in_screen);
On 2017/06/30 16:32:26, varkha (OOO on July 3) wrote:
> nit: ditto for gfx::Point - can we forward declare and move the include to
.cc?

Done.

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
ash/wm/overview/window_selector.h:106: const
std::vector<std::unique_ptr<WindowGrid>>& grid_list_for_testing() {
On 2017/06/30 16:32:26, varkha (OOO on July 3) wrote:
> nit: this method can be marked as const.

Done.

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
File ash/wm/overview/window_selector_item.cc (right):

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
ash/wm/overview/window_selector_item.cc:891: break;
On 2017/06/30 16:32:26, varkha (OOO on July 3) wrote:
> Would it be possible to calculate proper stacking_target in a loop above (or
> return if none) and just change the stacking without an additional loop?

Done.

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
File ash/wm/overview/window_selector_item.h (right):

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
ash/wm/overview/window_selector_item.h:183: // order so that the order of
windows is the same as when they entering
On 2017/06/30 16:32:26, varkha (OOO on July 3) wrote:
> nit: 'they' can be dropped.

Done.

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/splitview/split_...
File ash/wm/splitview/split_view_controller_unittest.cc (left):

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/splitview/split_...
ash/wm/splitview/split_view_controller_unittest.cc:107: const gfx::Rect
bounds(0, 0, 400, 400);
On 2017/06/29 17:46:23, oshima wrote:
> why this change?

Sorry, it was a mistake. Bring it back.

[xdai1, 2017-07-06 00:36:46]

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

[commit-bot: I haz the power, 2017-07-06 00:37:06]

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, 2017-07-06 00:53:18]

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

[commit-bot: I haz the power, 2017-07-06 00:53:20]

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

[xdai1, 2017-07-06 17:37:31]

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

[commit-bot: I haz the power, 2017-07-06 17:37:41]

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, 2017-07-06 18:55:34]

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

[commit-bot: I haz the power, 2017-07-06 18:55:35]

Dry run: This issue passed the CQ dry run.

[xdai1, 2017-07-13 18:38:52]

kindly ping?

[varkha, 2017-07-13 20:21:25]

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
File ash/wm/overview/window_selector.cc (right):

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
ash/wm/overview/window_selector.cc:153: return
split_view_controller->GetSnappedWindowBoundsInScreen(root_window,
On 2017/07/06 00:35:49, xdai OOO till Jul 13 wrote:
> On 2017/06/29 17:46:23, oshima wrote:
> > is it hard to make root_window parameter const?
> 
> The const_cast in line 589 is inevitable, either in line 589, or in
> split_view_controller.cc when calculating GetDisplayWorkAreaBoundsInScreen()
if
> I modify this function to accept const*.

I think we should try to convince ScreenUtil::GetDisplayWorkAreaBoundsInParent
that it could accept a (const Window*) as a parameter. But this seems separate
enough and even if possible would trigger a somewhat long chain of updates so
not for this CL.

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
File ash/wm/overview/window_selector_item.cc (right):

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
ash/wm/overview/window_selector_item.cc:891: break;
On 2017/07/06 00:35:49, xdai OOO till Jul 13 wrote:
> On 2017/06/30 16:32:26, varkha (OOO on July 3) wrote:
> > Would it be possible to calculate proper stacking_target in a loop above (or
> > return if none) and just change the stacking without an additional loop?
> 
> Done.

Thanks. I wanted to test this in local branch but I am currently seeing some
trouble when hiding captions in overview. Seems like a recent regression so I
will try to bisect and see if I can test this code with a few scenarios.

[varkha, 2017-07-13 22:43:01]

Thanks, lgtm, but please see my comment about not being able to drag widgets
with open modal dialogs - not sure if this is desirable.

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
File ash/wm/overview/window_selector_item.cc (right):

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
ash/wm/overview/window_selector_item.cc:891: break;
On 2017/07/13 20:21:25, varkha wrote:
> On 2017/07/06 00:35:49, xdai OOO till Jul 13 wrote:
> > On 2017/06/30 16:32:26, varkha (OOO on July 3) wrote:
> > > Would it be possible to calculate proper stacking_target in a loop above
(or
> > > return if none) and just change the stacking without an additional loop?
> > 
> > Done.
> 
> Thanks. I wanted to test this in local branch but I am currently seeing some
> trouble when hiding captions in overview. Seems like a recent regression so I
> will try to bisect and see if I can test this code with a few scenarios.

I was talking about http://crbug.com/741581. Bisected that to a skia roll so I
could test this CL and it seems OK in scenario that I was concerned about
(transient modal dialogs). Positioning of the open / save dialogs after drag in
split view seems to be suboptimal (it forces the window to be fullscreen) but
this is tangential.

[oshima, 2017-07-14 18:43:12]

lgtm

https://codereview.chromium.org/2955203002/diff/140001/ash/wm/overview/overvi...
File ash/wm/overview/overview_window_drag_controller.cc (right):

https://codereview.chromium.org/2955203002/diff/140001/ash/wm/overview/overvi...
ash/wm/overview/overview_window_drag_controller.cc:24: const int
kMinimiumDragOffset = 5;
nit: constexpr

https://codereview.chromium.org/2955203002/diff/140001/ash/wm/overview/overvi...
ash/wm/overview/overview_window_drag_controller.cc:28: const int
kScreenEdgeInsetForDrag = 200;
ditto

https://codereview.chromium.org/2955203002/diff/140001/ash/wm/overview/overvi...
File ash/wm/overview/overview_window_drag_controller.h (right):

https://codereview.chromium.org/2955203002/diff/140001/ash/wm/overview/overvi...
ash/wm/overview/overview_window_drag_controller.h:40: const gfx::Point&
location_in_screen);
nit: const?

[xdai1, 2017-07-18 17:36:45]

oshima@, varkha@, thanks for the review!

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
File ash/wm/overview/window_selector.cc (right):

https://codereview.chromium.org/2955203002/diff/60001/ash/wm/overview/window_...
ash/wm/overview/window_selector.cc:153: return
split_view_controller->GetSnappedWindowBoundsInScreen(root_window,
On 2017/07/13 20:21:25, varkha wrote:
> On 2017/07/06 00:35:49, xdai OOO till Jul 13 wrote:
> > On 2017/06/29 17:46:23, oshima wrote:
> > > is it hard to make root_window parameter const?
> > 
> > The const_cast in line 589 is inevitable, either in line 589, or in
> > split_view_controller.cc when calculating GetDisplayWorkAreaBoundsInScreen()
> if
> > I modify this function to accept const*.
> 
> I think we should try to convince ScreenUtil::GetDisplayWorkAreaBoundsInParent
> that it could accept a (const Window*) as a parameter. But this seems separate
> enough and even if possible would trigger a somewhat long chain of updates so
> not for this CL.

I filed a bug crbug.com/745871 to track this work. Will address it in a separate
CL.

https://codereview.chromium.org/2955203002/diff/140001/ash/wm/overview/overvi...
File ash/wm/overview/overview_window_drag_controller.cc (right):

https://codereview.chromium.org/2955203002/diff/140001/ash/wm/overview/overvi...
ash/wm/overview/overview_window_drag_controller.cc:24: const int
kMinimiumDragOffset = 5;
On 2017/07/14 18:43:11, oshima wrote:
> nit: constexpr

Done.

https://codereview.chromium.org/2955203002/diff/140001/ash/wm/overview/overvi...
ash/wm/overview/overview_window_drag_controller.cc:28: const int
kScreenEdgeInsetForDrag = 200;
On 2017/07/14 18:43:11, oshima wrote:
> ditto

Done.

https://codereview.chromium.org/2955203002/diff/140001/ash/wm/overview/overvi...
File ash/wm/overview/overview_window_drag_controller.h (right):

https://codereview.chromium.org/2955203002/diff/140001/ash/wm/overview/overvi...
ash/wm/overview/overview_window_drag_controller.h:40: const gfx::Point&
location_in_screen);
On 2017/07/14 18:43:11, oshima wrote:
> nit: const?

Done.

[xdai1, 2017-07-18 17:37:09]

The CQ bit was checked by xdai@chromium.org

[xdai1, 2017-07-18 17:37:10]

The patchset sent to the CQ was uploaded after l-g-t-m from varkha@chromium.org,
oshima@chromium.org
Link to the patchset: https://codereview.chromium.org/2955203002/#ps160001
(title: "Address varkha@ and oshima's comments. Rebase.")

[commit-bot: I haz the power, 2017-07-18 17:37:25]

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, 2017-07-18 18:57:58]

CQ is committing da patch.

Bot data: {"patchset_id": 160001, "attempt_start_ts": 1500399429163590,
"parent_rev": "bf51abc39e5e4a9fa172821d999c054fe6bb2ed0", "commit_rev":
"0c6d79c9a3a2bf404ef94220c389924541c92f0b"}

[commit-bot: I haz the power, 2017-07-18 18:58:10]

Description was changed from

==========
Cros Tablet Window management - Split Screen part II

Wire up the SplitViewController with the overview mode. It's a following
up CL of https://codereview.chromium.org/2960843004/.

Changes in this CL:
1. The split view mode can be initiated by dragging the window in
overview mode to the side of the screen
2. After one window is snapped to one side of the screen, all the other
overview windows will display in the other side of the screen, allowing
the user to select another window to snap. When two windows are snapped
to both sides of the screen, the overview mode will be ended.
3. The first snapped window will remain snapped until the user
explicitly exit the split view mode. All the other windows (incluing
newly created window) will be open in the other side of the screen.
Clicking/Tapping on the overview button also open the overview windows
in the other side of the screen.

Not covered in this CL:
1. The highlighted region showing where split will occur is not
   implemented in this CL.
2. The split divider is not implemented in this CL.

BUG=725683
==========

to

==========
Cros Tablet Window management - Split Screen part II

Wire up the SplitViewController with the overview mode. It's a following
up CL of https://codereview.chromium.org/2960843004/.

Changes in this CL:
1. The split view mode can be initiated by dragging the window in
overview mode to the side of the screen
2. After one window is snapped to one side of the screen, all the other
overview windows will display in the other side of the screen, allowing
the user to select another window to snap. When two windows are snapped
to both sides of the screen, the overview mode will be ended.
3. The first snapped window will remain snapped until the user
explicitly exit the split view mode. All the other windows (incluing
newly created window) will be open in the other side of the screen.
Clicking/Tapping on the overview button also open the overview windows
in the other side of the screen.

Not covered in this CL:
1. The highlighted region showing where split will occur is not
   implemented in this CL.
2. The split divider is not implemented in this CL.

BUG=725683

Review-Url: https://codereview.chromium.org/2955203002
Cr-Commit-Position: refs/heads/master@{#487542}
Committed:
https://chromium.googlesource.com/chromium/src/+/0c6d79c9a3a2bf404ef94220c389...
==========

[commit-bot: I haz the power, 2017-07-18 18:58:13]

Committed patchset #9 (id:160001) as
https://chromium.googlesource.com/chromium/src/+/0c6d79c9a3a2bf404ef94220c389...

[alph, 2017-07-18 21:45:59]

A revert of this CL (patchset #9 id:160001) has been created in
https://codereview.chromium.org/2978273002/ by alph@chromium.org.

The reason for reverting is: Broke ash_unittests
https://uberchromegw.corp.google.com/i/chromium.chromiumos/builders/Linux%20C....

[xdai1, 2017-07-19 20:57:10]

Patchset #10 (id:180001) has been deleted