Correctly update the popup window position

Correctly update the popup window position

It was updating the child window instead.
This CL hooks up the bounds change to the desktop widget correctly.

BUG=612270
TEST=fixed test harness to do the correct check.

Review-Url: https://codereview.chromium.org/2583873002
Cr-Commit-Position: refs/heads/master@{#442741}
Committed: https://chromium.googlesource.com/chromium/src/+/0aafa24f1ad6b4331bdb65db12ffc1842ba69b1d

[oshima, 2016-12-16 13:46:41]

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

[commit-bot: I haz the power, 2016-12-16 13:47:06]

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

[oshima, 2016-12-16 14:08:25]

Description was changed from

==========
Just update the size when the bounds is set on popup.

The location is already set in InitAsPopu, so this isn't
really necessary, but just update the size.

The method should set the bounds the toplevel widget, but
I couldn't find the correct way in desktop aura. I'll update
once I find it.

BUG=612270
==========

to

==========
Just update the size when the bounds is set on popup.

The location is already set in InitAsPopu, so this isn't
really necessary, but just update the size.

The method should set the bounds the toplevel widget, but
I couldn't find the correct way in desktop aura. I'll update
once I find it.

BUG=612270
==========

[oshima, 2016-12-16 14:08:25]

oshima@chromium.org changed reviewers:
+ bsep@chromium.org

[commit-bot: I haz the power, 2016-12-16 14:14:40]

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

[commit-bot: I haz the power, 2016-12-16 14:14:41]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[oshima, 2016-12-16 17:56:12]

Description was changed from

==========
Just update the size when the bounds is set on popup.

The location is already set in InitAsPopu, so this isn't
really necessary, but just update the size.

The method should set the bounds the toplevel widget, but
I couldn't find the correct way in desktop aura. I'll update
once I find it.

BUG=612270
==========

to

==========
Correctly update the popup window position

BUG=612270
==========

[oshima, 2016-12-16 17:56:20]

Patchset #2 (id:20001) has been deleted

[oshima, 2016-12-16 17:57:49]

Description was changed from

==========
Correctly update the popup window position

BUG=612270
==========

to

==========
Correctly update the popup window position

BUG=612270
TEST=fixed test harness to do the correct check.
==========

[oshima, 2016-12-16 17:57:55]

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

[commit-bot: I haz the power, 2016-12-16 17:58:31]

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

[oshima, 2016-12-16 18:06:09]

Patchset #1 (id:1) has been deleted

[oshima, 2016-12-16 18:07:17]

Description was changed from

==========
Correctly update the popup window position

BUG=612270
TEST=fixed test harness to do the correct check.
==========

to

==========
Correctly update the popup window position

It was updating the child window instead.
This CL hooks up the bounds change to the desktop widget correctly.

BUG=612270
TEST=fixed test harness to do the correct check.
==========

[oshima, 2016-12-16 18:07:17]

oshima@chromium.org changed reviewers:
+ sadrul@chromium.org

[oshima, 2016-12-16 18:07:24]

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

[commit-bot: I haz the power, 2016-12-16 18:08:01]

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

[commit-bot: I haz the power, 2016-12-16 18:51:00]

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

[commit-bot: I haz the power, 2016-12-16 18:51:01]

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

[sadrul, 2016-12-16 20:15:45]

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

https://codereview.chromium.org/2583873002/diff/60001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_view_aura.cc:598: return
window_->GetToplevelWindow();
On non-chromeos, I assume this returns the
|DesktopNativeWidgetAura::content_window_|? Is there a reason setting the bounds
on that does not work? (because it looks like setting the bounds on
|content_window_| should notify the DesktopWindowTreeHost, which should resize
the Widget too?)

[oshima, 2016-12-16 22:48:01]

On 2016/12/16 20:15:45, sadrul wrote:
>
https://codereview.chromium.org/2583873002/diff/60001/content/browser/rendere...
> File content/browser/renderer_host/render_widget_host_view_aura.cc (right):
> 
>
https://codereview.chromium.org/2583873002/diff/60001/content/browser/rendere...
> content/browser/renderer_host/render_widget_host_view_aura.cc:598: return
> window_->GetToplevelWindow();
> On non-chromeos, I assume this returns the
> |DesktopNativeWidgetAura::content_window_|? Is there a reason setting the
bounds
> on that does not work? (because it looks like setting the bounds on
> |content_window_| should notify the DesktopWindowTreeHost, which should resize
> the Widget too?)

I got the following check when I used GetToplevelWindow().

[32173:32173:1216/143842.278930:FATAL:desktop_screen_position_client.cc(46)]
Check failed: !desktop_native_widget || desktop_native_widget->GetNativeView()
!= window. 
#0 0x7f01ac7bee5e base::debug::StackTrace::StackTrace()
#1 0x7f01ac7e379b logging::LogMessage::~LogMessage()
#2 0x7f01a85e154c views::DesktopScreenPositionClient::SetBounds()
#3 0x7f01aa2ad1dd content::RenderWidgetHostViewAura::SetBounds()
#4 0x7f01aa2ac99d content::RenderWidgetHostViewAura::InitAsPopup()

I tried without dcheck, but it still didn't work. What's the proper fix?

[oshima, 2016-12-17 15:59:42]

uploaded new patch that always uses toplevel window. please let me know what you
think. thanks!

[oshima, 2016-12-17 16:32:08]

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

[commit-bot: I haz the power, 2016-12-17 16:32:18]

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

[commit-bot: I haz the power, 2016-12-17 16:58:27]

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

[commit-bot: I haz the power, 2016-12-17 16:58:28]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[sadrul, 2016-12-19 18:08:56]

https://codereview.chromium.org/2583873002/diff/80001/ui/views/widget/desktop...
File ui/views/widget/desktop_aura/desktop_screen_position_client.cc (right):

https://codereview.chromium.org/2583873002/diff/80001/ui/views/widget/desktop...
ui/views/widget/desktop_aura/desktop_screen_position_client.cc:48: return;
It looks like DesktopNativeWidgetAura::OnBoundsChanged() does not do anything. I
think it would be better if this happened there? That's how NativeWidgetAura
resizes the corresponding views::Widget, looks like, and it'd be good to follow
the same codepath for desktop too, instead of having this special case here.

[oshima, 2016-12-20 23:55:32]

https://codereview.chromium.org/2583873002/diff/80001/ui/views/widget/desktop...
File ui/views/widget/desktop_aura/desktop_screen_position_client.cc (right):

https://codereview.chromium.org/2583873002/diff/80001/ui/views/widget/desktop...
ui/views/widget/desktop_aura/desktop_screen_position_client.cc:48: return;
On 2016/12/19 18:08:56, sadrul wrote:
> It looks like DesktopNativeWidgetAura::OnBoundsChanged() does not do anything.
I
> think it would be better if this happened there? That's how NativeWidgetAura
> resizes the corresponding views::Widget, looks like, and it'd be good to
follow
> the same codepath for desktop too, instead of having this special case here.

Did you mean DesktopNativeWidgetTopLevelHandler::OnWindowBoundsChannged? I
looked into the code,
and I actually didn't understand how this is supposed to work. The bounds has to
be set here,
before being set on the window, otherwise the window will be moved inside the
widget, and
that's what seems to be happening. (The content_window's bounds is moved inside
root window)

Am I reading wrong?

[Bret, 2016-12-21 00:04:25]

lgtm

https://codereview.chromium.org/2583873002/diff/80001/ui/views/widget/desktop...
File ui/views/widget/desktop_aura/desktop_screen_position_client.cc (right):

https://codereview.chromium.org/2583873002/diff/80001/ui/views/widget/desktop...
ui/views/widget/desktop_aura/desktop_screen_position_client.cc:51: //
DesktopNativeWidgetAura.
nit: since you're explicitly handling the dchecked case above, this
comment+dcheck is unnecessary.

[sadrul, 2016-12-21 02:00:13]

On 2016/12/20 23:55:32, oshima (OOO til Jan 5th) wrote:
>
https://codereview.chromium.org/2583873002/diff/80001/ui/views/widget/desktop...
> File ui/views/widget/desktop_aura/desktop_screen_position_client.cc (right):
> 
>
https://codereview.chromium.org/2583873002/diff/80001/ui/views/widget/desktop...
> ui/views/widget/desktop_aura/desktop_screen_position_client.cc:48: return;
> On 2016/12/19 18:08:56, sadrul wrote:
> > It looks like DesktopNativeWidgetAura::OnBoundsChanged() does not do
anything.
> I
> > think it would be better if this happened there? That's how NativeWidgetAura
> > resizes the corresponding views::Widget, looks like, and it'd be good to
> follow
> > the same codepath for desktop too, instead of having this special case here.
> 
> Did you mean DesktopNativeWidgetTopLevelHandler::OnWindowBoundsChannged?

No. I mean DesktopNativeWidgetAura::OnBoundsChanged()
(https://cs.chromium.org/chromium/src/ui/views/widget/desktop_aura/desktop_nat...)

> I
> looked into the code,
> and I actually didn't understand how this is supposed to work. The bounds has
to
> be set here,
> before being set on the window, otherwise the window will be moved inside the
> widget, and
> that's what seems to be happening. (The content_window's bounds is moved
inside
> root window)
> 
> Am I reading wrong?

[oshima, 2016-12-21 21:47:40]

On 2016/12/21 02:00:13, sadrul wrote:
> On 2016/12/20 23:55:32, oshima (OOO til Jan 5th) wrote:
> >
>
https://codereview.chromium.org/2583873002/diff/80001/ui/views/widget/desktop...
> > File ui/views/widget/desktop_aura/desktop_screen_position_client.cc (right):
> > 
> >
>
https://codereview.chromium.org/2583873002/diff/80001/ui/views/widget/desktop...
> > ui/views/widget/desktop_aura/desktop_screen_position_client.cc:48: return;
> > On 2016/12/19 18:08:56, sadrul wrote:
> > > It looks like DesktopNativeWidgetAura::OnBoundsChanged() does not do
> anything.
> > I
> > > think it would be better if this happened there? That's how
NativeWidgetAura
> > > resizes the corresponding views::Widget, looks like, and it'd be good to
> > follow
> > > the same codepath for desktop too, instead of having this special case
here.
> > 
> > Did you mean DesktopNativeWidgetTopLevelHandler::OnWindowBoundsChannged?
> 
> No. I mean DesktopNativeWidgetAura::OnBoundsChanged()
>
(https://cs.chromium.org/chromium/src/ui/views/widget/desktop_aura/desktop_nat...)
> 
> > I
> > looked into the code,
> > and I actually didn't understand how this is supposed to work. The bounds
has
> to
> > be set here,
> > before being set on the window, otherwise the window will be moved inside
the
> > widget, and
> > that's what seems to be happening. (The content_window's bounds is moved
> inside
> > root window)
> > 
> > Am I reading wrong?

I think it is still wrong because as I mentioned, we need to adjust the bounds
before the bounds is set, not after.

I also looked intothe current logic in DesktopScreenPositionClient. and looks
like it is for embedded widgets,
such as omnibox, status bubble where it uses NativeWidgetAura, not desktop one.

So my guess is that this (ability to move the desktop widget using
Window::SetBoundsInScreen) was never implemented,
but it just looked working in most cases because menu never really move after it
is shown?

[oshima, 2016-12-22 02:12:40]

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

[commit-bot: I haz the power, 2016-12-22 02:12:55]

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

[commit-bot: I haz the power, 2016-12-22 02:14:49]

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

[commit-bot: I haz the power, 2016-12-22 02:14:49]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-device-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-xcode-...)
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[sadrul, 2017-01-03 16:33:04]

On 2016/12/21 21:47:40, oshima (OOO til Jan 5th) wrote:
> On 2016/12/21 02:00:13, sadrul wrote:
> > On 2016/12/20 23:55:32, oshima (OOO til Jan 5th) wrote:
> > >
> >
>
https://codereview.chromium.org/2583873002/diff/80001/ui/views/widget/desktop...
> > > File ui/views/widget/desktop_aura/desktop_screen_position_client.cc
(right):
> > > 
> > >
> >
>
https://codereview.chromium.org/2583873002/diff/80001/ui/views/widget/desktop...
> > > ui/views/widget/desktop_aura/desktop_screen_position_client.cc:48: return;
> > > On 2016/12/19 18:08:56, sadrul wrote:
> > > > It looks like DesktopNativeWidgetAura::OnBoundsChanged() does not do
> > anything.
> > > I
> > > > think it would be better if this happened there? That's how
> NativeWidgetAura
> > > > resizes the corresponding views::Widget, looks like, and it'd be good to
> > > follow
> > > > the same codepath for desktop too, instead of having this special case
> here.
> > > 
> > > Did you mean DesktopNativeWidgetTopLevelHandler::OnWindowBoundsChannged?
> > 
> > No. I mean DesktopNativeWidgetAura::OnBoundsChanged()
> >
>
(https://cs.chromium.org/chromium/src/ui/views/widget/desktop_aura/desktop_nat...)
> > 
> > > I
> > > looked into the code,
> > > and I actually didn't understand how this is supposed to work. The bounds
> has
> > to
> > > be set here,
> > > before being set on the window, otherwise the window will be moved inside
> the
> > > widget, and
> > > that's what seems to be happening. (The content_window's bounds is moved
> > inside
> > > root window)
> > > 
> > > Am I reading wrong?
> 
> I think it is still wrong because as I mentioned, we need to adjust the bounds
> before the bounds is set, not after.
> 
> I also looked intothe current logic in DesktopScreenPositionClient. and looks
> like it is for embedded widgets,
> such as omnibox, status bubble where it uses NativeWidgetAura, not desktop
one.
> 
> So my guess is that this (ability to move the desktop widget using
> Window::SetBoundsInScreen) was never implemented,
> but it just looked working in most cases because menu never really move after
it
> is shown?

This is not a problem on ChromeOS, right? What codepath is used on ChromeOS that
takes care of positioning things correctly? I suspect it's from the
NativeWidgetAura::OnBoundsChanged() override that calls into
Widget::OnNativeWidgetMove()/OnNativeWidgetSizeChanged(). If that is indeed the
case, then I am suggesting we should do the same in
DesktopNativeWidgetAura::OnBoundsChanged(). Unless you are saying we do not
actually use DesktopNativeWidgetAura for these popups (which would be weird)?

[oshima, 2017-01-05 20:27:40]

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

[commit-bot: I haz the power, 2017-01-05 20:28:03]

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-01-05 20:30:02]

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

[commit-bot: I haz the power, 2017-01-05 20:30:04]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-device-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-xcode-...)
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)

[oshima, 2017-01-05 20:30:22]

On 2017/01/03 16:33:04, sadrul wrote:
> On 2016/12/21 21:47:40, oshima (OOO til Jan 5th) wrote:
> > On 2016/12/21 02:00:13, sadrul wrote:
> > > On 2016/12/20 23:55:32, oshima (OOO til Jan 5th) wrote:
> > > >
> > >
> >
>
https://codereview.chromium.org/2583873002/diff/80001/ui/views/widget/desktop...
> > > > File ui/views/widget/desktop_aura/desktop_screen_position_client.cc
> (right):
> > > > 
> > > >
> > >
> >
>
https://codereview.chromium.org/2583873002/diff/80001/ui/views/widget/desktop...
> > > > ui/views/widget/desktop_aura/desktop_screen_position_client.cc:48:
return;
> > > > On 2016/12/19 18:08:56, sadrul wrote:
> > > > > It looks like DesktopNativeWidgetAura::OnBoundsChanged() does not do
> > > anything.
> > > > I
> > > > > think it would be better if this happened there? That's how
> > NativeWidgetAura
> > > > > resizes the corresponding views::Widget, looks like, and it'd be good
to
> > > > follow
> > > > > the same codepath for desktop too, instead of having this special case
> > here.
> > > > 
> > > > Did you mean DesktopNativeWidgetTopLevelHandler::OnWindowBoundsChannged?
> > > 
> > > No. I mean DesktopNativeWidgetAura::OnBoundsChanged()
> > >
> >
>
(https://cs.chromium.org/chromium/src/ui/views/widget/desktop_aura/desktop_nat...)
> > > 
> > > > I
> > > > looked into the code,
> > > > and I actually didn't understand how this is supposed to work. The
bounds
> > has
> > > to
> > > > be set here,
> > > > before being set on the window, otherwise the window will be moved
inside
> > the
> > > > widget, and
> > > > that's what seems to be happening. (The content_window's bounds is moved
> > > inside
> > > > root window)
> > > > 
> > > > Am I reading wrong?
> > 
> > I think it is still wrong because as I mentioned, we need to adjust the
bounds
> > before the bounds is set, not after.
> > 
> > I also looked intothe current logic in DesktopScreenPositionClient. and
looks
> > like it is for embedded widgets,
> > such as omnibox, status bubble where it uses NativeWidgetAura, not desktop
> one.
> > 
> > So my guess is that this (ability to move the desktop widget using
> > Window::SetBoundsInScreen) was never implemented,
> > but it just looked working in most cases because menu never really move
after
> it
> > is shown?
> 
> This is not a problem on ChromeOS, right? What codepath is used on ChromeOS
that
> takes care of positioning things correctly? I suspect it's from the
> NativeWidgetAura::OnBoundsChanged() override that calls into
> Widget::OnNativeWidgetMove()/OnNativeWidgetSizeChanged().

Nope. On ChromeOS, setting widget bounds is same as settings bounds on aura
window.
The coordinate has to be updated so that the bounds is correctly converted to
the one
relative to parent container.

On desktop, setting bounds on aura window and on widget can have different
meaning
when specifying the screen coordinates.

ScreenPositionClient is the one that is responsible for doing the right thing to
set
aura window bounds in screen.

> If that is indeed the
> case, then I am suggesting we should do the same in
> DesktopNativeWidgetAura::OnBoundsChanged(). Unless you are saying we do not
> actually use DesktopNativeWidgetAura for these popups (which would be weird)?

This does not work because we need to adjust the bounds *BEFORE* updating the
widget/window bounds.
It may be possible to set the bounds back, but it makes things more complicated
IMO.

If it's still not clear, let's have a quick chat over IM or VC.

[oshima, 2017-01-05 20:32:19]

Patchset #5 (id:120001) has been deleted

[oshima, 2017-01-05 20:43:02]

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

[commit-bot: I haz the power, 2017-01-05 20:43:52]

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-01-05 21:39:39]

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

[commit-bot: I haz the power, 2017-01-05 21:39:39]

Dry run: This issue passed the CQ dry run.

[sadrul, 2017-01-09 15:58:39]

OK. I was going to suggest doing the work in a LayoutManager, but I am not sure
that would be much better than doing it from ScreenPositionClient. So this lgtm.
Can you please add a test in desktop_aura for the change?

[oshima, 2017-01-10 23:03:35]

On 2017/01/09 15:58:39, sadrul wrote:
> OK. I was going to suggest doing the work in a LayoutManager, but I am not
sure
> that would be much better than doing it from ScreenPositionClient. So this
lgtm.
> Can you please add a test in desktop_aura for the change?

Added a test. I confirmed that the test fails without my change (with and
without DCHECK in the
screen position client)

[oshima, 2017-01-10 23:04:00]

The CQ bit was checked by oshima@chromium.org

[oshima, 2017-01-10 23:04:00]

The patchset sent to the CQ was uploaded after l-g-t-m from bsep@chromium.org,
sadrul@chromium.org
Link to the patchset: https://codereview.chromium.org/2583873002/#ps160001
(title: "test added")

[commit-bot: I haz the power, 2017-01-10 23:04:26]

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-01-11 00:25:38]

CQ is committing da patch.

Bot data: {"patchset_id": 160001, "attempt_start_ts": 1484089440003580,
"parent_rev": "63dcc86b88089a26a04bd3a55964f8c25df52b69", "commit_rev":
"0aafa24f1ad6b4331bdb65db12ffc1842ba69b1d"}

[commit-bot: I haz the power, 2017-01-11 00:26:11]

Description was changed from

==========
Correctly update the popup window position

It was updating the child window instead.
This CL hooks up the bounds change to the desktop widget correctly.

BUG=612270
TEST=fixed test harness to do the correct check.
==========

to

==========
Correctly update the popup window position

It was updating the child window instead.
This CL hooks up the bounds change to the desktop widget correctly.

BUG=612270
TEST=fixed test harness to do the correct check.

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

[commit-bot: I haz the power, 2017-01-11 00:26:16]

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

[malaykeshav, 2017-03-07 00:42:25]

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

The reason for reverting is: Breaking M57
crbug/698627.