Avoid using a stale timestamp (from the last user interaction with the
application) when a message arrives from D-Bus requesting that a new
window be created.
In this case the most-correct thing that we can do is to use no
timestamp at all.
We modify gdk_x11_display_set_startup_notification_id() to allow a NULL
value to mean "reset everything" and then call this function
unconditionally on receipt of D-Bus activation requests. The result
will be that a missing desktop-startup-id in the platform-data struct
will reset the timestamp.
Under their default configuration metacity and mutter will both map
windows presented with no timestamp in the foreground. This could
result in false-positive, but there is very little we can do about that
without the original timestamp from the user event.
https://bugzilla.gnome.org/show_bug.cgi?id=752000
If we don't find Xft values in the X resource db, simply fall
back to the values that are hardcoded in /etc/X11/Xresources
anyway. Extra trickery with likely-made-up screen dimensions
is not going to yield better results, and only makes for a
deeper rabbit hole when debugging.
Support was added for GDK_HINT_ASPECT in
gdk_quartz_window_set_geometry_hints though with one restriction:
min_aspect and max_aspect have to be equal, which I believe corresponds
to the most common usage. A warning will be printed if this condition is
not met but min_aspect will be used anyway.
Under Wayland, fullscreen/maximized windows may not cover the entire
area when a size increment is specified.
Ignore size increments for fullscreen/maximized windows just like most
window managers do under X11 so that windows with size increments can
still be fullscreen or fully maximized under Wayland as well.
https://bugzilla.gnome.org/show_bug.cgi?id=751368
We used to "invalidate" scroll valuators, so the next scroll event could
be used as the base for the next scroll deltas. This has the inconvenience
that it invariably consumes the first event received after enter and,
due to interactions with WM overeager passive button grabs, there's a
possibility we don't scroll at all if we receive interleaved "smooth
scroll" XI_Motion events and XI_Enter events (Normally triggered by regular
scroll wheels in mice).
In order to fix this, and at the expense of some sync-call overhead on
XI_Enter events (one XIQueryDevice call per slave device), query the
current scroll valuator state for all the slaves of the entered pointer,
so we do know beforehand the right base values. If new devices are plugged
while the pointer is on top of the client, the initialized scroll values
will match the valuators'.
https://bugzilla.gnome.org/show_bug.cgi?id=750994https://bugzilla.gnome.org/show_bug.cgi?id=750870
gdk_x11_device_xi2_window_at_position() may attempt to push/pop
a few error trap pairs while traversing the window tree. Move it
outside the server grab, and around the multiple XIQueryPointer
calls we may do here.
https://bugzilla.gnome.org/show_bug.cgi?id=751739
We mistakenly forced the "STRING" type, which was able to confuse higher
layer helpers like gtk_selection_data_get_uris(). This fixes a crash
happening anytime a drop is attempted on a GtkPlacesSidebar.
Currently, due to the lack of progress information in the Wayland DnD
protocol, we assume a DnD operation is finished after the first
data_source.send is finished (It's either that or leaving stuck grabs).
This however breaks previous assumptions that dest widgets can request
the data multiple times, even in response to GtkWidget::drag-motion.
This leaves us with a NULL owner for the DnD atom when we aren't
finished receiving wl_data_source events yet, causing a crash.
This commit fixes the crash, the behavior left is still far from
desirable though...
And force the ungrab on it, instead of the slave, in the case of
local DnD drop. This avoids confusions on the pointer events spawn
from DnD, as GDK doesn't think anymore those are from a slave device.
Most namely, it fixes the stuck grab when finishing DnD on the
same app it was started from.
We currently only hold the last offer received, which is wrong, as both
are independent and have different life cycles.
This means we have to store per-selection wl_data_offer and targets, and
maintain these as appropriate from the clipboard/DnD specific entry points.
This oddly can be reproduced with weston+weston-dnd, when dragging
anything from GTK+ into weston-dnd, it will insist on picking its
custom application/x-wayland-dnd-flower mimetype, and this request
forwarded by the compositor, even if GTK+ didn't announce it on
its wl_data_source mimetype list. (What should probably happen here
is that the request is silenced, and/or weston-dnd picks (null))
This should be harmless, we are leaking though the fd in that case,
because the emission of GdkEventSelection on an unhandled mimetype
results in NOP. In order to avoid this, we should check whether the
mimetype is supported at all on the backend code and possibly close
the fd, this involves storing these in the first place.
https://bugzilla.gnome.org/show_bug.cgi?id=751414
If the other peer requests data too fast (too rare/unlikely though),
we might receive multiple gdk_wayland_selection_request_target() calls
with no ending gdk_wayland_selection_check_write(), in which case the
fd is leaked as no GOutputStream was created to take over it.
https://bugzilla.gnome.org/show_bug.cgi?id=751414
We weren't catching all the places where the AsyncWriteData operation
should be cancelled, which could happen if we repeatedly request the
same target on different fds.
https://bugzilla.gnome.org/show_bug.cgi?id=751414
At the moment we create the AsyncWriteData, the ownership of the
fd is granted to the GOutputStream, and the fd set to -1, so at
this moment we're just silently getting EBADFD.
This partially reverts 25885ca600, the initialization of .fd
to -1 is valid and stays though.
https://bugzilla.gnome.org/show_bug.cgi?id=751414
On X11 this is something the windowing system does for us, which the
wayland backend should emulate, being grabs completely client-side.
So, if the grab and current focus windows differ, make sure we emit
focus/crossing events as it corresponds to the grab device.
This was being done so only on pointers. Internally, a GdkDeviceGrabInfo
is kept for each of the master pointer/keyboard, failing to do this for
keyboards results in a stuck keyboard grab.
https://bugzilla.gnome.org/show_bug.cgi?id=748892
The fd must be closed on async_write_data_free(), but we should also
initialize it to -1 so gdk_wayland_selection_check_write() doesn't wrongly
pick the stdin fd.
https://bugzilla.gnome.org/show_bug.cgi?id=751414
A subsurface positioning operation only takes effect when the parent
surfaces state is applied. If a subsurface is mapped and positioned, but
the parent surface state is not immediately committed, the relative
position of the subsurface is undefined and may be placed incorrectly.
To avoid this undefined state, always request that the parent surface
should be committed after mapping a subsurface so that the position
operation will take effect.
https://bugzilla.gnome.org/show_bug.cgi?id=751098
Background patterns are often updated when style changes. In many cases,
the new pattern will match the previous. We can optimize out the
invalidation that will occur upon resetting the same pattern.
An pass_through window is something you can draw in but does not
affect event handling. Normally if a window has with no event mask set
for a particular event then input events in it go to its parent window
(X11 semantics), whereas if pass_through is enabled the window below
the window will get the event. The later mode is useful when the
window is partially transparent. Note that an pass-through windows can
have child windows that are not pass-through so they can still get events
on some parts.
Semantically, this behaves the same as an regular window with
gdk_window_set_child_input_shapes() called on it (and re-called any
time a child is changed), but its far more efficient and easy to use.
This allows us to fix the testoverlay input stacking test.
https://bugzilla.gnome.org/show_bug.cgi?id=750568https://bugs.freedesktop.org/show_bug.cgi?id=90917
If a menu was not attached to any widget, we try to calculate its
position given where the grabbed pointer is and what window has its
focus. Previously we failed to do so if a "transfer window" was used
for the grab, and this patch adds a code path that, if the menu window
itself didn't have the grab, look for the transfer window and get the
grab device from there.
https://bugzilla.gnome.org/show_bug.cgi?id=748951
If a position was already explicitly set, don't try to guess the
position of popup menus by looking at the pointer position, just use
the set coordinates.
https://bugzilla.gnome.org/show_bug.cgi?id=748951
According to the xdg-shell protocol specification the (x, y) coordinates
passed when creating a popup surface is relative to top left corner of
the parent surface, but prior to this patch, if the parent surface
was an xdg_surface, we'd position it relative to top left corner of the
window geometry of that xdg_surface.
https://bugzilla.gnome.org/show_bug.cgi?id=749717
