cross-client surface references

[Jonas Ådahl]

On Fri, Jul 03, 2015 at 11:52:53AM +0200, Alexander Larsson wrote:
> 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.

With "see" I suppose you mean "be aware and map", because it wouldn't
see the content.

For the record, the original foreign surface idea was about putting less
privileged clients's surfaces inside a more privileged client's parent
surface, which indeed is quite the opposite of whats the intention here.

But yes, that sounds like it should work as well, and would be less
complex regarding mapping multiple windows.

For this to be allowed, we'd have to either put all of this inside
xdg_shell, or introduce something like "xdg_shell compatible surface"
that we can say is Ok to pass as surfaces to xdg_surface.set_parent,
since it is now strictly limited to a xdg_surface, but that is a minor
problem.


Jonas