What we do and don't expose to client toolkits

Gerry Boland gerry.boland at canonical.com
Sun Sep 4 12:17:10 UTC 2016


Hi,
replt inline

On 01/09/16 13:02, Alan Griffiths wrote:
> When clients toolkits provide hints to place child surfaces using the
> existing functions:
> 
>     mir_surface_spec_attach_to_foreign_parent();
>     mir_connection_create_spec_for_tip();
>     mir_connection_create_spec_for_menu(); or the proposed,
>     mir_surface_spec_set_placement()
> 
> the toolkit wants to know where the child surface actually ends up in
> order to render appropriately.
> 
> We currently have a policy not to provide any location information to
> clients, so I want to be sure that I don't propose anything controversial.
> 
> In discussion with Chris he suggests that sending a
> PlacementRelativeToParent{dx, dy} message is the right solution.

That sounds ok to me. Client gave detailed information (rect+offsets) to
window manager about how to position the child surface relative to
parent, and WM replies with the final position (relative to parent).

Qt does want to know this information anyway.


> 
> Doing this opens up an opportunity for clients to:
> 
>     1. probe the display boundaries using dummy placement requests. (The
>     point is to provide the location before they render.)
> 
>     2. parent (and place) everything they do on a fullscreen surface
>     (which they can conceal from the user). It does limit them to
>     surface types that can be parented.
> 

I can't think of how to avoid these issues, as if policy has limits,
then those limits can be probed. And a fullscreen surface with alpha can
be easily used by a malicious client to give appearance of window
positioning, something we cannot prevent with Mir alone, but with shell
UI hints.

Thanks
-Gerry



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20160904/e6b54487/attachment.pgp>


More information about the Mir-devel mailing list