cross-client surface references

[Pekka Paalanen]

On Mon, 6 Jul 2015 11:25:53 -0700
Bill Spitzak <spitzak at gmail.com> wrote:

> On Fri, Jul 3, 2015 at 3:10 AM, Jonas Ådahl <jadahl at gmail.com> wrote:
> 
> >
> > > 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.
> >
> 
> I feel like this has to be part of the basic Wayland protocol, and should
> work for every object a client can create.

No way. That would be a complete re-design of the whole protocol.

> The client that gets a "key" must also use the correct interface and makes
> a new objectId that is exactly the same thing. It is not an
> "xdg_shell_compatible_surface", the object actually *is* an xdg_surface.

Multiple "handles" to the same underlying server-side object from
completely asynchronous contexts (different processes). I can't see
that ending well at all, considering that *nothing* we have ever
designed for Wayland accounts for that.

> I think it is ok if the client getting the key can do *any* requests on the
> resulting object. It is way too difficult to separate the requests a client
> actually needs from dangerous ones.
> 
> I'm not sure what to do with events. It seems like errors and responses to
> requests should only go to the client that made the request. But
> destruction must go to all clients. And input events it is hard to say, I
> would try just sending them to the first client, and see if anything more
> complicated is needed.

Destruction cannot "go" anywhere. The server cannot choose to destroy a
protocol object of one client at arbitrary times, even if it was
requested by another client. We simply do not have the messaging for
this, nor the extensive machinery required to solve the races.

Assuming the races can even be solved.

What does "destruction" even mean? Destroying the protocol object of
one client, or the underlying server-side object? Can you even define
that universally? It's easy to say that destroying a shared xdg_surface
object also destroys the underlying server-side object, but what if you
shared an object like wl_compositor? Can you give a simple universal
rule on what happens? Obviously the object underlying the wl_compositor
protocol object cannot be destroyed, that would not make any sense; but
then, what sense does the rule make?

If the server-side object disappears, what happens? How could you ever
define that in a way that would work for everything?

Let's take this relatively simple case of one client providing a parent
surface and another client providing a dialog surface that should be
related to the parent. What should happen if the parent disappears?
Should the client with the dialog be notified?

Or what if the server-side object gets destroyed only when the last
protocol object associated with it is destroyed? A client shares an
xdg_surface, stuff happens, the client destroys the xdg_surface
assuming the window gets unmapped, but oops, someone else is holding a
ref to it, so it actually doesn't unmap.

What then, if the xdg_surface is shared but the related wl_surface is
not, and the wl_surface gets destroyed? Xdg-shell defines what happens
in a non-shared case, but how does that translate to the other client?

I believe going for "this should work for everything" is not feasible,
because we did not design for it from the start, and we cannot break
the protocol now.


Thanks,
pq