When a key binding is removed, and a trigger key sequence is dispatched
before the idle callback that resolves and updates the actual binding,
we should handle that gracefully.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3711>
Two new fields: ref_count and removed, are added to MetaKeyHandler, and
it would be freed only if the ref count has reached 0. When handler is
removed from key_handlers GHashTable, key_handler_destroy() would mark
removed as TRUE, and do an unref. handler->removed is checked in
get_keybinding, and binding with handler removed would not be used.
Also in MetaKeyBinding, it now has the ownership of the name field, to
avoid it being freed before logging. Create or copy a binding would
do a ref inc for handler, and free one would unref handler.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1870.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3711>
When a client resizes on its own, make sure the new size is passed
through the window constraints machinery directly, to trigger any
potential window management rule that might apply.
Fix a couple of tests to make use of this behavior by introducing a new
'wait_size' command that waits until a window has been resized to a
expected size.
This replaces the fix introduced in 0e736af301 ("window: Ensure
constraints after a Wayland client resize").
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3700>
Starting the timeout to move from hidden to suspended before the window
is mapped means we don't have a previous window configufration which we
need to get the new window configuration with the suspended state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3731>
Sometimes the test runners are saturated with other work. Bump the test
timeouts by a multiplier of 5 with the hope that they now will be much
more likely to have time to finish in time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3735>
These functions are specific for X11 windows only so we should check
if the passed window is an X11 one, not just a MetaWindow since we're
casting to the actual type at later point.
Fixes changes part of commit e1e6534eb
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3727>
If a window sends a configure stacking request, we were comparing the
active window with the event window even though they were different
client types (e.g. wayland and x11).
This was leading to a critical error, so let's handle this by ensuring
that the active window is of the same kind of the event window before
doing x11-specific checks. Behaving as different applications in case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3727>
Because `meta_kms_impl_device_simple_initable_init` is called in the
middle of `meta_kms_device_new`, the crtcs list for `MetaKmsDevice`
has not been populated yet. And thus the loop to detect missing
cursor planes and create fake ones never iterated. But the crtcs list
does already exist in `MetaKmsImplDevice` so iterate over that instead.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3264
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3676>
Prior to commit 5dfed8a431, the MetaWaylandKeyboard would always remember
the last key press serial, and consider it valid after the key was released,
as long as no other key presses/releases happened in between.
That commit improved things so that MetaWaylandKeyboard can track multiple
keys being pressed simultaneously, but also changed so that the serial for
a key press is immediately forgotten after the key press event was received.
This may break in situations like testing or keyboard macros where key
press and release is handled in a quick sucession, so the client reaction
to the key press (e.g. popping up a menu) might arrive too late.
Add a sort of spiritual successor to this handling, and make keyboard
press serials corresponding to the last key up forgotten at the next
key press/release received.
Fixes: 5dfed8a431 ("wayland: Preserve serial for all pressed keys")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3458
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3721>
We did not track the current surface (i.e. the logical focus) too
thoroughly, so there might be chances that a stale surface pointer
here becomes the focus. Track its destruction (like it's done at e.g.
MetaWaylandPointer) and unset the current surface early, in order
to avoid possible invalid memory access.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3372
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3715>
It seems only the iconcache used to use it, but this is gone since
commit d16ddc42ce.
Even before that, the Xrender usage was removed in commit 556e7694de,
albeit leaving a redundant include <X11/extensions/Xrender.h> in its
place then, which comes from libXrender.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3716>
Fix an obvious copy paste error that slipped through the cracks.
Fortunately it doesn't have a visual impact for well behaving clients
but only makes us not hit direct-scanout paths, assuming no other bugs
in the stack.
Fixes: f21762ea6e (wayland: Add support for preferred_buffer_scale/transform)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3717>
This call is meant to replace meta_wayland_keyboard_get_focus_client(),
since we will always have a MetaWaylandSeat with an input focus (or not),
but we may or may not have a MetaWaylandKeyboard.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3707>
When there is a new owner but there is no matching mime type we clear
the saved mimetype and the saved clipboard but an outstanding async
meta_selection_transfer_async can set the saved clipboard.
Abort the async transfer when we have a new owner.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3678>
The precondition checks in meta_selection_source_memory_new can return
NULL if the mimetype is NULL but callers expect the error to be set when
NULL is returned.
Let's just make sure we never call it with a NULL mimetype.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3678>
The current code checking keyboard serials for popup/grab
validation is a bit simple, tracking one key press exclusively.
This may break expectations if a client uses a serial
corresponding to a previous key that is still pressed.
Keep track of the serials corresponding to all pressed keys,
and ensure these are reset across focus changes, since the
validity of those serials is already outdated. The code does
still keep track of a single (last) key release serial, since
the validity lifetime is somewhat underdefined with those if
we keep track of multiple keys simultaneously.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3267
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3644>
Instead of initializing to 'suspended', which will send the `SUSPENDED`
xdg_toplevel state, set it to hidden at first. If the window is placed
on an inactive workspace, it'll eventually enter the 'suspended' state,
but will have had some time in non-suspended state to get map, even if
not visibly.
This fixes inital suspended state when mapping a window maximized.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3229
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3475>
This, in contrast to meta_window_should_be_showing() reports whether a
window should be showing despite not being showable. This is useful to
know the intended visibility state that should happen in the immediate
future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3475>
d991961ae changed this code from client rect to buffer rect to account
for the fact that for SSD windows the decorations are now included in
the bounding region, but it kept the variable name as client_area and
the comment was also still referring to the client rect.
Fixes: d991961ae ("x11: Use input region from frame window for decorated windows")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3697>
When updating the input region we check whether the input shape reported
by XShape matches the bounding region of a window to determine when it
was not set by the client. We would then use a NULL input region instead
which always matches the full size of the window. The code however was
using the client rect for this comparison, which does not include the
window frame. Since d991961a the frame is considered part of the input
region.
This meant that for SSD windows where the input region would match the
bounding region, we would not detect that and fail to set the input
region to NULL, but instead set it to the reported input shape.
Usually this would not be the case due to the GTK frame window having
shadows and a resize region, but in the presence of an issue that causes
GTK to wrongly detect _GTK_FRAME_EXTENTS as not supported, GTK would not
draw shadows or set an input shape. And due to GTK not updating its
input shape, there would be no further calls to
meta_window_x11_update_input_region() after the initial one.
The input region would therefore remain at the fixed size from the
initial call. This was causing windows to become click-through outside
of the region corresponding to their initial size after being resized.
Fixes: d991961ae ("x11: Use input region from frame window for decorated windows")
Related: https://gitlab.gnome.org/GNOME/gtk/-/issues/6558
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3404
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3697>
