Calling gdk_device_get_direction can trigger a
notify::direction emissions, since the X11 backend
determines the direction on demand. Prevent that by
forcing the direction to be determined ahead of time.
Fixes: #5311
For some of the a11y states, calling gtk_accessible_reset_state
can change the type of the state value from boolean or tristate
to undefined.
Handle that, instead of throwing criticals.
Related: !4910
Currently, the GdkSurfaceX11 implementation relies that the upper
layers hid the surface before destruction, and that no
GdkSurfaceClass.compute_resize happened between them. If these
circumstances happened, there would be a compute_size timeout left
dangling after the surface got destroyed, poking at incorrect data
later on. Something that looks like this was reported in the
recent mutter-x11-frames "SSD frames server":
mutter-x11-frames:423016): GLib-GObject-WARNING **: 19:41:16.869: invalid unclassed pointer in cast to 'GtkWindow'
Thread 1 "mutter-x11-fram" received signal SIGTRAP, Trace/breakpoint trap.
g_logv (log_domain=0x7ffff7f7c4f8 "GLib-GObject", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=<optimized out>) at ../../../glib/gmessages.c:1433
1433 ../../../glib/gmessages.c: No such file or directory.
(gdb) bt
#0 g_logv (log_domain=0x7ffff7f7c4f8 "GLib-GObject", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=<optimized out>) at ../../../glib/gmessages.c:1433
#1 0x00007ffff73470ff in g_log (log_domain=log_domain@entry=0x7ffff7f7c4f8 "GLib-GObject", log_level=log_level@entry=G_LOG_LEVEL_WARNING, format=format@entry=0x7ffff7f84da8 "invalid unclassed pointer in cast to '%s'")
at ../../../glib/gmessages.c:1471
#2 0x00007ffff7f72892 in g_type_check_instance_cast (type_instance=type_instance@entry=0x5555558e04b0, iface_type=<optimized out>) at ../../../gobject/gtype.c:4144
#3 0x00007ffff791e77d in toplevel_compute_size (toplevel=<optimized out>, size=0x7fffffffe170, widget=0x5555558e04b0) at ../../../gtk/gtkwindow.c:4227
#4 0x00007ffff7f4f3b0 in g_closure_invoke (closure=0x555555898cc0, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0x7fffffffdeb0, invocation_hint=invocation_hint@entry=0x7fffffffde30)
at ../../../gobject/gclosure.c:832
#5 0x00007ffff7f62076 in signal_emit_unlocked_R
(node=node@entry=0x55555588feb0, detail=detail@entry=0, instance=instance@entry=0x55555560e990, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffdeb0)
at ../../../gobject/gsignal.c:3796
#6 0x00007ffff7f68bf5 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffe050) at ../../../gobject/gsignal.c:3549
#7 0x00007ffff7f68dbf in <emit signal ??? on instance 0x55555560e990 [GdkX11Toplevel]> (instance=<optimized out>, signal_id=<optimized out>, detail=detail@entry=0) at ../../../gobject/gsignal.c:3606
#8 0x00007ffff7a8de96 in gdk_toplevel_notify_compute_size (toplevel=<optimized out>, size=size@entry=0x7fffffffe170) at ../../../gdk/gdktoplevel.c:112
#9 0x00007ffff7a4b15a in compute_toplevel_size (surface=surface@entry=0x55555560e990 [GdkX11Toplevel], update_geometry=update_geometry@entry=1, width=width@entry=0x7fffffffe220, height=height@entry=0x7fffffffe224)
at ../../../gdk/x11/gdksurface-x11.c:281
#10 0x00007ffff7a4c3b2 in compute_size_idle (user_data=0x55555560e990) at ../../../gdk/x11/gdksurface-x11.c:356
#11 0x00007ffff733f67f in g_main_dispatch (context=0x55555563f6e0) at ../../../glib/gmain.c:3444
#12 g_main_context_dispatch (context=context@entry=0x55555563f6e0) at ../../../glib/gmain.c:4162
#13 0x00007ffff733fa38 in g_main_context_iterate (context=0x55555563f6e0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../../../glib/gmain.c:4238
#14 0x00007ffff733fcef in g_main_loop_run (loop=loop@entry=0x5555560874a0) at ../../../glib/gmain.c:4438
#15 0x0000555555557de0 in main (argc=<optimized out>, argv=<optimized out>) at ../src/frames/main.c:68
It perhaps makes sense to warn in these situations, but either way
it sounds like gdk_surface_x11_finalize() could enforce the correct
behavior by ensuring there is no dangling timeouts/data. This commit
does that.
8455b9ac74 seems to have introduced a problem where we can wind
up focusing no widget at all if the `while (parent)` loop doesn't
find a widget it can successfully move the focus to. This 'fixes'
that by falling back to doing the previous thing if we make it
all the way through that loop without moving the focus. Thanks to
@coreyberla for a hint to improve the implementation.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There's 2 things broken here:
- The mask was calculated on top of the GDK button (i.e. skipping
4-7 buttons), so GDK_BUTTON4_MASK and GDK_BUTTON5_MASK were not
assigned. This is now calculated on the (continuous) BTN_ evcodes
so it is guaranteed that the next 2 physical buttons (i.e.
back/forward) get these two places in the mask assigned.
- Furthermore, these buttons would be pushed to places in the
modifier mask that they didn't belong to. It is now checked hard
that only the first 5 buttons enable a modifier flag.
Overall, this ensures that no event masks with bonkers values are
forwarded, and that no stale implicit grabs are left after additional
buttons are pressed.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5301
We can get spurious focus-out/-in pairs when
the editable label is in a popover that gets
a Wayland keyboard enter event as a result of
clicking the editable label.
A timeout isn't a great solution, but nothing
better is available right now.
Fixes: #4864
Only clear a queued move_focus if the widget
we are focusing is actually visible.
This was happening in some cases when popovers
are dismissed by clicking outside, and it was
causing us to miss proper focus updates that
were already queued.
This partially undoes changes from 3dbf5038fa.
That commit did two things:
1) Move the focus update to after-paint time
2) Change from grabbing focus to the visible parent
to calling move_focus (TAB)
The second part did have the unintended consequence
of moving focus laterally.
Fixes: #4903
Empty/zero bounds are sent by the Wayland compositor if there are no
valid bounds to report, e.g. if there are no connected monitors. Report
this to GTK, which uses this to clamp calculated sizes, as INT_MAX, so
that clamping isn't done until there are actual valid bounds to clamp
to.
This fixes clients sometimes shrinking to their minimum size during
hotplugs or after having suspended the session.
(cherry picked from commit b3a3a6ceb1)
We shouldn't assume there is always a monitor to derive bounds from.
If there is no monitor, pass empty bounds, as this matches what
xdg_toplevel.configure_bounds do in this case.
(cherry picked from commit 148c133674)
Even though the argument is non-nullable, GTK sometimes incurs in that
by itself by destroying the surface while the event is in flight. This
is the case of popping down a GtkDropdown. When this happens we simply
ignore the crossing event, but we should let it through instead, the
compositor did not send it in vain and we possibly still have pointer
state to undo.
Drop the surface checks, so that the event is propagated along GTK.
Doing reset() on the text widgets after commit and delete_surrounding
is still too eager for some IMs (e.g. those that expect being able
to commit text while keeping a preedit buffer shown).
However, reset() is more of a "synchronize state" action on Wayland,
and it is still desirable to do that after changes that do come from
the IM (e.g. requesting the new surrounding text and cursor/anchor
positions). Notably here, the text_input protocol may still come up
with a preedit string after this state synchronization happens.
Shuffle the code so that the text widgets do not reset() the IM
context after text is deleted or committed, but the Wayland IM does
apply its practical effects after these actions happen. This keeps
the Wayland IM fully up-to-date wrt text widget state, while not
altering the ::commit and ::delete-surrounding-text behavior for
other IM context implementations.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5200
Fixes: 5b78fe2721 (gtktextview: Also reset IM context after IM...)
Fixes: 7c0a395ff9 (gtktext: Also reset IM context after IM...)
Fixes: 52ac71b972 (gtktextview: Shuffle the places doing IM reset)
Fixes: 9e29739e66 (gtktext: Shuffle the places doing IM reset)
The X11 backend can mark modifiers like Shift as consumed even if they
aren't actually active, which seems to be something to do with making
shortcuts like `<Control><Shift>plus` and `<Control>plus` work as
intended regardless of whether the plus symbol is obtained by pressing
Shift and a key (like `+/=` on American, British or French keyboards)
or not (like `*/+` on German keyboards).
However, this can go badly wrong when the modifier is *not* pressed.
For example, terminals normally have separate bindings for `<Control>c`
(send SIGINT) and `<Control><Shift>c` (copy). If we disregard the
consumed modifiers completely, when the X11 backend marks Shift as
consumed, pressing Ctrl+c would send SIGINT *and* copy to the clipboard,
which is not what was intended.
By masking out the members of `consumed` that are not in `state`, we
get the same interpretation for X11 and Wayland, and ensure that
keyboard shortcuts that explicitly mention Shift can only be triggered
while holding Shift. It continues to be possible to trigger keyboard
shortcuts that do not explicitly mention Shift (such as `<Control>plus`)
while holding Shift, if the backend reports Shift as having been
consumed in order to generate the plus keysym.
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/5095
Bug-Debian: https://bugs.debian.org/1016927
Signed-off-by: Simon McVittie <smcv@debian.org>
The filetransfer protocol says to use
application/vnd.portal.filetransfer, but I used
application/vnd.portal.files when I implemented the
protocol. Oops.
This commit dds the correct mimetype, but we still
support the old one to preserve interoperatibility
with existing flatpaks using GTK 4.6.
Fixes: #5182
We need to register the portal mime types before
the others to prefer them, doing this call async
messes up that ordering.
This is effectively reverting 69fb3648b2
