Mir does not react to client requests to reposition child windows

Bug #1603086 reported by Andreas Pokorny
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mir
Confirmed
Medium
Unassigned
MirAL
Fix Released
High
Alan Griffiths
mir (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

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.

Tags: gtk-mir

Related branches

description: updated
Revision history for this message
Alan Griffiths (alan-griffiths) wrote :

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

Changed in miral:
status: New → Confirmed
importance: Undecided → High
assignee: nobody → Alan Griffiths (alan-griffiths)
Changed in mir:
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
Alan Griffiths (alan-griffiths) wrote :

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.

tags: added: gtk-mir
Changed in mir:
importance: Low → Medium
Revision history for this message
Alan Griffiths (alan-griffiths) wrote :

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.

Revision history for this message
Alan Griffiths (alan-griffiths) wrote :

Oops! Misread my own logging:

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

description: updated
description: updated
Changed in miral:
status: Confirmed → In Progress
Changed in miral:
status: In Progress → Fix Committed
Changed in miral:
status: Fix Committed → Fix Released
Revision history for this message
Michał Sawicz (saviq) wrote :

Syncing task from Mir.

Changed in mir (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.