Issue 644895 link

Starred by 1 user

Issue metadata

Status:	Archived
Owner:	jamescook@chromium.org
Closed:	Sep 2016
Cc:	msw@chromium.org sky@chromium.org mustash-bugs@google.com
Components:	Internals>Services>WindowService
EstimatedDays:	----
NextAction:	----
OS:	Chrome
Pri:	2
Type:	Bug
Proj-Mustash-Mash VerifyIn-55 VerifyIn-56 VerifyIn-57 VerifyIn-58 VerifyIn-59 VerifyIn-60 VerifyIn-61

In mash shelf is offscreen on second display

Project Member Reported by kylec...@chromium.org, Sep 7 2016

Issue description

The shelf is not visible on the second display when running in mash under Ozone X11 with './chrome --mash --multi-display'. If you make the second display larger (by dragging the window) you can see that the shelf is offset by the size of the first display but is otherwise drawing. The coordinates for the shelf widget are translated offscreen by this piece of code:

https://cs.chromium.org/chromium/src/ash/common/shelf/shelf_layout_manager.cc?q=shelf_layout_manager.cc&sq=package:chromium&dr&l=579

The shelf container has the right coordinates but the shelf widget does not.

Comment 1 by jamescook@chromium.org, Sep 8 2016

Cc: -jamescook@chromium.org
Components: MUS
Owner: jamescook@chromium.org
Status: Started (was: Untriaged)

I'll take a look. I wonder if the screen position client (or whatever we're using to do root -> screen coordinate transforms) is busted.

Comment 2 by jamescook@chromium.org, Sep 8 2016

Cc: sky@chromium.org

Might be related to  issue 615552  "WmWindowMus needs to support SetBoundsInScreen and associated BoundsInScreenBehavior"

What I know at this point:

Everything looks correct in non-mash ash.

Everything in the window server's window hierarchy (ctrl-alt-shift-s) matches the ash window hierarchy, which is good.

From the WmWindow perspective in ash (hit ctrl-alt-shift-w):
* The shelf widget's x-position in parent is 800, which is wrong. It should be 0.
* All parents up to the root have x-position 0, which is correct.

The WmWindow for the shelf correctly transforms the desired bounds-in-root to bounds-in-screen (x = 0 to x = 800).

I can do set/get of bounds-in-screen on views::Widget and they are correct (800). However, WmWindow::GetBoundsInScreen() returns 1600.

Settings the bounds-in-screen on the views::Widget (x = 800) sends screen bounds to NativeWidgetMus (800) but also to ui::Window (800). The latter should be in-parent (0). I think this is the problem.

NativeWidgetAura::SetBounds() uses aura::client::ScreenPositionClient to set the position of widgets. The implementation in ScreenPositionController has interesting logic around moving windows between displays. We might need something similar in mus in the long run.

Project Member

Comment 3 by bugdroid1@chromium.org, Sep 9 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fa697bc0a0332fc8ab5684f4c4366797d4b5aeab

commit fa697bc0a0332fc8ab5684f4c4366797d4b5aeab
Author: jamescook <jamescook@chromium.org>
Date: Fri Sep 09 04:43:55 2016

mash: Fix shelf on second display appearing in wrong position

NativeWidgetMus::SetBounds() was not correcting for the display origin.

Also fix NativeWidgetMus::GetBoundsInScreen(), which had the same problem.

BUG= 645291 , 644895 
TEST=run mash with --multi-display, shelf appears on second display

Review-Url: https://codereview.chromium.org/2328523003
Cr-Commit-Position: refs/heads/master@{#417505}

[modify] https://crrev.com/fa697bc0a0332fc8ab5684f4c4366797d4b5aeab/ui/views/mus/native_widget_mus.cc
[modify] https://crrev.com/fa697bc0a0332fc8ab5684f4c4366797d4b5aeab/ui/views/mus/native_widget_mus.h