... not when we do an update.
We only repick when we handle events, not when we update. Perhaps
this is a mistake.
Since update runs before handle_event, this means that when we
drop a grab, update will notice the NULL surface, since we haven't
repicked after the event, and then we'll repick the correct surface.
The end result is that you see a root cursor after a grab ends,
rather than the correct window cursor.
This doesn't fix it, since the current surface becomes NULL when
we start the grab. But it does make the code here more correct when
we fix that bug.
Sophisticated clients, like those using ClutterGtk, will have more
than one focused resource per client, as both Clutter and GDK will
ask for a wl_pointer / wl_keyboard. Support this naturally using
the same "hack" as Weston: multiple resource lists, where we move
elements from one to the other.
In order to support multiple pointers for the same client, we're
going to need to kill it.
This will cause crashes for now, but will be fixed by the next
commit.
default_grab_focus tries to add implicit grab semantics where
focus won't take effect if there's a pointer button down. This
is not what we want for popup grabs at all, as it's perfectly
valid to want to drag on a menu while there's a button down.
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
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.
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.
If the client destroys the pointer resource, we shouldn't unfocus the
surface, and we should regrab it when the client gets the pointer
resource again.
This also fixes a crash at surface destruction because of the unchecked
wl_link_remove that will happen on both pointer and surface destroy.
Something noticed on code inspection. If we have a popup grab,
it will always return FALSE. The code here clearly meant to continue
if we had an existing popup grab from an existing client.
Both the pointer/keyboard resource and surface resource can be destroyed
at any point in the destruction process, so we need to have destroy
listeners on both. To make the code easier to follow, rename ->focus
to ->focus_surface at the same time, and rearrange the code so that
the two of them are always grouped together.
To prevent corruption, our focus listener needs to be removed even when
the surface is destroyed. So, bailing out when pointer->focus->resource
is NULL just isn't good enough.
When we have a new client, we potentially set the focus on one of its
surfaces when we map it but the client might not have called
wl_seat.get_keyboard/pointer yet. When it finally calls
get_keyboard/pointer we must then register its resource as the
focus_resource which means that we can only return early if
focus_resource is already set.
https://bugzilla.gnome.org/show_bug.cgi?id=719725
