Mir does not react to client requests to reposition child windows

[Andreas Pokorny]

Due to the order in which certain window types are created in gtk, the gdk backend for mir gets two positioning requests when constructing a tooltip.
Tooltips are represented as menus in the mir backend of gdk.
The second surface spec contains the right relative position, but it happens after the surface was constructed by the backend. The default window manager policies in mir and miral seem to ignore the new position.

[Alan Griffiths (alan-griffiths)]

Only becomes significant for lp:mir when we backport the default Window Management from lp:miral

[Alan Griffiths (alan-griffiths)]

anpok_> hm the new gedit shows a tooltip when you rest the mouse pointer over one of the editor tabs
<anpok_> it should be a few pixels underneath the cursor, but comes up in the center of the window

Tried this (in xenial) but the client never attempts to reposition the "tooltip" it just creates it. (I'm not sure the surface type is "tooltip" either.)

But the bug is real - I just need a working test case.

[Alan Griffiths (alan-griffiths)]

Further investigation:

1. There is no mir_toolkit API for updating the "zone" on a tooltip.
2. The zone of a tooltip isn't a placement hint. (It is the area of the parent where the tooltip is active.)
3. gedit/gtk-mir is re-creating the "tooltip", not repositioning it.
4. The gedit window is of type mir_surface_type_gloss, not mir_surface_type_tip
5. There is no mir_toolkit API for placing a "gloss"
6. There is no mir_toolkit API for updating the attachment "rect&edge" on menus (& surfaces with "foreign" parents).
7. Miral window management only handles "rect&edge" when initially placing child surfaces.

[Alan Griffiths (alan-griffiths)]

Oops! Misread my own logging:

4. The gedit window is of type mir_surface_type_normal, not mir_surface_type_tip

[Michał Sawicz (saviq)]

Syncing task from Mir.