cross-client surface references

[Bill Spitzak]

On 07/09/2015 02:21 AM, Jonas Ådahl wrote:

> That is more or less what was the idea before the thread derailed.

I have no idea why you think my proposal "derailed" this when I was 
attempting to describe EXACTLY the same thing you are, except I replaced 
"fd" with a "key" which I figured is a 128-bit random number or a text 
representation of that number.

> Something like:
>
> low-priv-client:
>
> xdg_surf = xdg_shell.get_xdg_surface
> fd = export(xdg_surf)
> * pass fd to high-priv-client via dbus *

In my version:

   key = export(xdg_surf)
   * pass key to high-priv-client via any mechanism that can send a 
128-bit number, such as using argv.

> high-priv-client:
>
> * receive fd from low-priv-client via dbus *
> xdg_foreign = import(fd)

In my version
   * recieve key by whatever mechanism
   xdg_foreign = import(key, xdg_surface)

I think the import needs to indicate the interface it expects. This 
allows the child to use a different version of the api, and insure the 
correct wl_proxy is created.

> xdg_surf = xdg_shell.get_xdg_surface
> xdg_surf.set_parent(xdg_foreign)
>
> I think that if we clarify what happens if the exported surfaces
> disappears (which is the race you are referring to I suppose),

That is why I said there would need to be a destroy event.

> if
> we force the set_parent(foreign) to always stack above the foreign tree
> (similar to how subsurfaces stacking works), what would the security
> implications be?

Arrgh! As I have posted about 10 times now, it is EXACTLY how subsurface 
stacking works, and it should be using the SAME api! The only difference 
between a child window and a subsurface is that the compositor is 
allowed to insert other surfaces between a child and it's parent.

I'm sorry I'm being abrasive in my posts but it seems I am hitting a 
brick wall. I try really hard to describe an idea, and then EXACTLY the 
same idea is posted as "here is what we want before Bill derailed it!"