New issue
Advanced search Search tips

Issue 899388 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

Window Service: Make it easier to show widgets on a specific display

Project Member Reported by msw@chromium.org, Oct 26

Issue description

Window Service: Make it easier to show widgets on a specific display

See comments on this CL and the cumbersome resulting code encountered here:
https://chromium-review.googlesource.com/c/chromium/src/+/1287255/6/chrome/browser/ui/views/crostini/crostini_app_restart_view.cc#37

Basically the issue boils down to:
1) WS clients can't supply an aura::Window context to views::Widget::InitParams for the display if they don't already have a window on that display (classic Ash would just get the root window for the display from the shell or similar).
2) We have views::Widget::InitParams::mus_properties[ws::mojom::WindowManager::kDisplayId_InitProperty], but that seems to only work for [Single Process?] Mash (it should just work all the time, letting clients just specify the preferred size and display id).
3) It seems like attempts to set the window bounds in screen coordinates to force the window to appear on an extended display doesn't work in all scenarios (it should just work all the time, but this is probably not the preferred approach, as we'd like the consolidated window centering/placement code to just work off of the preferred size and display id)

There's an opportunity here to make this easier for clients to initialize Widgets, and/or use DialogDelegate::CreateDialogWidget.
 

Sign in to add a comment