cross-client surface references

[Alexander Larsson]

On fre, 2015-07-03 at 17:24 +0800, Jonas Ådahl wrote:
> 
> As an option prior to ending up with taking the nested compositing 
> path,
> I had a proposal that sounds similar to what you are talking about:
> 
> http://lists.freedesktop.org/archives/wayland-devel/2013
> -March/008093.html
> 
> What it does is allowing mapping a wl_surface with another client
> pushes content to. In the linked RFC, the intention was to allow 
> mapping
> it only as a subsurface, having the clients have some private method 
> for
> doing size synchronization. Doing the same by allowing mapping an
> xdg_surface is more complicated I imagine, since one cannot control 
> the
> commit timing of the foreign surface if its not a subsurface, but 
> maybe
> a wl_foreign_surface could solve that some other way.
> 
> Another issue with the linked RFC is that it creates a wl_surface 
> from
> some other object than wl_compositor, so that would have to change.
> 
> When it was brought up, there were also ideas by using file 
> descriptors
> some how as handles, passing around that instead, without having to 
> have
> a global "surface ID" namespace of some kind.
> 
> Other limitations with this is that such a surface wouldn't be able 
> to
> create popup menus (xdg_popup) or sub windows (xdg_surface), so maybe
> that is a deal breaker. How to direct input was another unsolved
> question.

Yes, this is a deal breaker. You can't write a file selector dialog
without menus. Also, overall this seems to be the wrong design. The
more privileged client in this case is the file selector part, so we
should give minimal access to it from the file-requestor. I.e. it seems
wrong that the sandboxed client should map the out-of-sandbox file
dialog.

> Maybe what is needed is an xdg_foreign. The Open File dialog provider
> client (I don't think it should be part of the server process) would
> create a xdg_surface, but before committing it, it'd "export" it 
> similar
> to the linked RFC and some how share it with another client via D
> -Bus.
> The client wanting to open a file would then import the xdg_surface 
> by
> creating a xdg_foreign from the shared handle. The xdg_foreign would 
> have
> functionality that should be provided, for example set_parent but not
> configure_ack.

This would work, but it still feels wrong to me. It has the same
priority-inversion as before (the less privileged clients gets to see
the more privileged one). It also limits what the "open file dialog"
client can do. For instance it can't open two (consecutive) surfaces
both with the other surface as the parent.
I think the sandboxed app should create a xdg_foreign for *its*
toplevel, and then the "open file dialog" should be able to use this as
a parent for its xdg_surfaces.
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl at redhat.com            alexander.larsson at gmail.com 
He's an uncontrollable albino senator with a secret. She's a bloodthirsty 
thirtysomething safe cracker with a knack for trouble. They fight crime!