GitLab

This patch fixes disposition/misplacement of menu windows and let the
Wayland compositor decide how to place the windows if their pixels
cannot be shown on one display or if they are partly going to be hidden
because of being shown too close to some edges of a display.

First of all, Chromium positions windows using screen coordinates.
As long as Wayland does not provide global coordinates, the client
does not know the position of windows in screen coordinates and
always assumes that they are located on 0,0. What's left for us to do
is to translate bounds from screen coordinates to relative to parent
coordinates, which is easy to do.

Secondly, WaylandWindow re-positions nested menus back to the right side
of parent menus (if the size of a top level window is close or equal to the
work area of a display) and let Wayland compositor decide how to position
them based on calculated anchor rect, anchor and gravity. The exception
for this is based on the maximized state of a top level window.
If it's maximized, then the nested windows are not re positioned
and left on the left side of the parent menu windows.

Also, WaylandWindow must be able to recalculate origin back from
relative to parent to be relative to top level window aka on screen
location.

The unittests exercises all those mentioned cases and make sure
WaylandWindow is able to calculated bounds correctly (the values
are taken by manual usage of the Chromium browser and logs).

PS XdgVersionV5Test/WaylandWindowTest.AdjustPopupBounds/0 is skipped
as long as it does not support xdg positioner.

Test: XdgVersionV6Test/WaylandWindowTest.AdjustPopupBounds/0
Bug: 927280
Change-Id: I30573620562e7bc5dfd3a69487326bcda49fc6ed
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1474654Reviewed-by: Robert Kroeger <rjkroege@chromium.org>
Commit-Queue: Maksim Sisov <msisov@igalia.com>
Cr-Commit-Position: refs/heads/master@{#638616}