Previously, a sequence like this would crash a client:
=> surface.attach(buffer)
=> buffer.destroy()
The correct behavior is to wait until we release the buffer before
destroying it.
=> surface.attach(buffer)
=> surface.attach(buffer2)
<= buffer.release()
=> buffer.destroy()
The protocol upstream says that "the surface contents are undefined"
in a case like this. Personally, I think that this is broken behavior
and no client should ever do it, so I explicitly killed any client
that tried to do this.
But unfortunately, as we're all well aware, XWayland does this.
Rather than wait for XWayland to be fixed, let's just allow this.
Technically, since we always copy SHM buffers into GL textures, we
could release the buffer as soon as the Cogl texture is made.
Since we do this copy, the semantics we apply are that the texture is
"frozen" in time until another newer buffer is attached. For simple
clients that simply abort on exit and don't wait for the buffer event
anyhow, this has the added bonus that we'll get nice destroy animations.
If we have a CLICKING grab op we still need to send events to xwayland
so that we get them back for gtk+ to process thus we can't steer
wayland input focus away from it.
https://bugzilla.gnome.org/show_bug.cgi?id=726123
meta_wayland_seat_repick() can be called in various cases while mutter
has a GRAB_OP ongoing which means we could be sending wrong pointer
enter/leave events.
https://bugzilla.gnome.org/show_bug.cgi?id=726123
In particular we need to know about all key events to keep the xkb
state reliable even if the event is then consumed by a global shortcut
or grab and never reaches any wayland client.
We also need to keep track of all pressed keys at all times so that we
can send an updated set or pressed keys to the focused client when a
grab ends.
https://bugzilla.gnome.org/show_bug.cgi?id=722847
Any given clutter event carries the modifier state as it was before it
occured but, for the wayland modifiers event, we want the state
including the current event.
To fix this, we'll keep our xkb_state instance around instead of the
serialized mods.
https://bugzilla.gnome.org/show_bug.cgi?id=722847
Which is used for Wayland popup grabs.
The issue here is that we don't want the code that raises or focuses
windows based on mouse ops to run while a client has a grab.
We still keep the "old" grab infrastructure in place for now, but
ideally we'd replace it eventually with a better grab-op infrastructure.
Do to a bad mixup, the surface listener was never actually fired.
This was accidentally fixed as part of a refactoring in a27fb19,
but the surface listener was broken, and we started crashing. To
fix, just remove the surface listener, as we've mostly been testing
without it.
This is not needed since the instance is being destroyed and in fact
actively harmful when code called from other handlers disconnects us
for other reasons. In that case we might crash because the
disconnection doesn't prevent other handlers from running in the
current signal emission and thus we try to remove ourselves from an
empty list.
This changes the user data of all surface extensions resources to be
the MetaWaylandSurface instead of the MetaWaylandSurfaceExtension,
which means that we no longer need all these pesky wl_container_ofs
in implementations.
