Events from compositor for non-existing objects are silently ignored in wayland-client
libwayland-client
, as part of its logic to handle destruction races in the protocol, silently ignores events from the compositor to objects that have already been destroyed. However, in the process it also ignores events to objects that never existed in the first place.
An example of this is if the compositor creates an object with wl_resource_create
and then sends an event to it right away, without first sending to the client the event that would create it. In this situation, from the point of view of the client it'll look exactly as if the message had never been sent in the first place.
We discovered this in wayland-rs
, which does a distinction between objects that have existed but are now destroyed, versus IDs that have never been assigned to an object at all. We encountered existing code that did exactly what I described in the previous paragraph, causing the wayland-rs
-based client to consider this as a protocol error.
It looks to me like a clear misbehavior from the compositor, but in the same time simply ignoring the message rather than crashing in this case does seem sensible for the client. Is the expected behavior in such a case specified somewhere?
I understand that, due to ID reuse, it is impossible to differentiate these two cases with certainty. The only situation this can actually be observed is when this occurs on an ID that had never been allocated before. In any case, for the sake of debuggability, I'd suggest that when libwayland-clients
drops an event, it should be signaled in the output of the WAYLAND_DEBUG
log, rather than be completely silent. This would certainly help in detecting such compositor bugs.