When Xwayland confines, the surface dimensions will include the server
side window manager decorations. We don't want the decorations to be
included in the constraint region so intersect the calculated input
region with the parts of the buffer rect that is not part of the window
frame.
https://bugzilla.gnome.org/show_bug.cgi?id=771859
Put the conditions for enabling a pointer constraint in a helper
function, and use that in both maybe_enable() and maybe_remove(). The
constraint region checking is still only done in maybe_enable()
however.
This changes the conditions for maybe disabling the constraint on focus
change and other trigger points, namely it makes constraints by Xwayland
not disable when they shouldn't due to the constraining window being an
override-redirect window.
https://bugzilla.gnome.org/show_bug.cgi?id=771859
When the grab is cancelled, for example because of an Alt-tab, VT
switch etc, disable or remove (depending on the constraint type) the
constraint. This avoids a re-entry issue when the focus is returned and
the focus listener tries to re-enable a disabled constraint.
https://bugzilla.gnome.org/show_bug.cgi?id=771859
Dismiss the popup when the grab is cancelled, so that if the grab is
ended for whatever reason (such as VT switching or the last pointer
being disconnected), it doesn't try to end the grab when it isn't
active.
This fixes a crash when VT switching back and forth while a popup grab
is active.
https://bugzilla.gnome.org/show_bug.cgi?id=771858
Previously a grab could suddenly end without the grabber knowing
anything about it. Some grabs assume they won't suddenly end without
notice, and can use then new 'cancel' vfunc to be notified.
Currently a grab is cancelled when a new one is started (i.e. in
meta_wayland_pointer_grab_start()), when a non-popup compositor wide
event route is initiated, and when the seat looses the pointer
capability.
https://bugzilla.gnome.org/show_bug.cgi?id=771858
Instead of using meta_wayland_pointer_end_grab() which focuses the new
grab, add a new helper mean to be used to reset the grab state without
changing the pointer focus. When using this function, the call site is
supposed to explicitly manage focus.
https://bugzilla.gnome.org/show_bug.cgi?id=771646
Make the caller of focus setting check whether there is a pointer to
update the focus state of. It makes it more obvious what to expect, as
the call would be a no-op in when no pointer is present.
Grabbing is still allowed without the presence of a pointer because it
is used by popups even on touch-only systems.
https://bugzilla.gnome.org/show_bug.cgi?id=771646
Make the caller of focus setting and grab starting check whether there
is a keyboard to update the focus state or start grabbing. It makes it
more obvious what to expect, as the call would be a no-op in when no
keyboard is present.
https://bugzilla.gnome.org/show_bug.cgi?id=771646
The variable name 'l' usually refers to a GList iterator, but here it's
just a short hand for a specific list. Stop using this shorthand, since
it just makes it harder to read what list is used.
https://bugzilla.gnome.org/show_bug.cgi?id=771646
The order doesn't only affect the visual layout, but also which action
cancels the dialog (and therefore responds to Escape). It is completely
surprising that this triggers a destructive action like force-quit, so
swap the actions to wait when the dialog is cancelled.
https://bugzilla.gnome.org/show_bug.cgi?id=737109
GNOME Shell's window matching currently fails frequently with Flatpak
applications, as one of the primary hints used to link windows with
.desktop files - the WM_CLASS - no longer matches when flatpak renames
the exported .desktop file. Luckily, Flatpak provides us with a fail-safe
way to map from the PID to the corresponding application ID, so expose an
appropriate method that allows GNOME Shell to reliably match windows to
the corresponding Flatpak app.
https://bugzilla.gnome.org/show_bug.cgi?id=772614
In order to kill a window, on both X11 and wayland we first try to
kill(3) the corresponding process, so we can add the newly added
get_client_pid() method to share that code.
https://bugzilla.gnome.org/show_bug.cgi?id=772613
It is often useful to identify the client process that created
a particular window, however the existing meta_window_get_pid()
method relies on _NET_WM_PID, which is only available on X11 and
depends on applications to set it correctly (which may not even
be possible when the app runs in its own PID namespace as Flatpak
apps do). So add a get_client_pid() method that uses windowing
system facilities to resolve the PID associated with a particular
window.
https://bugzilla.gnome.org/show_bug.cgi?id=772613
Previously the focus was reset implicitly by a memset() on the whole
MetaWaylandPointer struct. When MetaWaylandPointer was turned into a
GObject, this was not possible any more, and the focus was not updated
properly.
https://bugzilla.gnome.org/show_bug.cgi?id=771646
Going through the global mode pool and then checking if the mode is
available for a given output is pointless work since we can look at
the output's available modes directly.
This implicitly changes how we choose the default mode since, instead
of relying on the sort order of the global modes array, we now rely on
the sort order of the output modes array. Still not ideal, but at
least it makes more sense since the global array is essentially
unsorted.
https://bugzilla.gnome.org/show_bug.cgi?id=772176
This isn't technically needed and, in fact, makes us default to
interlaced modes in some cases which isn't desirable.
Note that X doesn't account for these flags either for its mode
refresh rates.
https://bugzilla.gnome.org/show_bug.cgi?id=772176
As the m format specifier doesn't consume any arguments, the number
of varargs currently doesn't match the number of specifiers; the
failed transform may be relevant, so include it in the message
instead of removing the excess argument.
There may be other windows managing selection whose events are seen in
our GDK event filter, like st-clipboard in gnome-shell, we should in
that case not interfere on Selection/SelectionRequest events that are
not meant for us.
This fixes an odd feedback loop where requesting clipboard contents from
wayland results in a XConvertRequest call and a SelectionRequest event
that is interpreted by mutter as a request from another X11 client, so
the current data source is poked for content, which happens to be the
X11 bridge, which does a XConvertRequest to get contents... This is only
broken after the many nested async operations create enough pipes and
cancellables to run out of fds.
Adding checks to ensure only events meant to our "selection owner"
window are managed prevent this unintended loop to happen in the first
place.
https://bugzilla.gnome.org/show_bug.cgi?id=760745
backends/meta-input-settings.c:1245:27: error: format '%lx' expects
argument of type 'long unsigned int', but argument 3 has type 'guint64
{aka long long unsigned int}' [-Werror=format=]
Commit a4fb7ef5a3 dropped translations of our internal cogl/clutter
forks, which broke the local-based text direction support. Instead
of bringing back translations just for this purpose, we can re-use
GTK's translations which use the same technique.
https://bugzilla.gnome.org/show_bug.cgi?id=771549
Those will be unseen by g-s-d/g-c-c, so no settings will be written on
disk for those. Still, look up an ID correctly in this case instead of
crashing.
https://bugzilla.gnome.org/show_bug.cgi?id=771628
When we mess with a window actor's visibility from the shell side
(yes, I know :-( ), we should at least restore the proper visibility
when we're done with it ...
https://bugzilla.gnome.org/show_bug.cgi?id=771536
A xdg_popup, when active, always has a parent surface. However, a popup
created may immediately become invalid, for example when it is not
granted a grab, in which case it won't be assigned a parent since it
will never be mapped.
This case needs to be handled elsewhere, as one cannot assume a
MetaWaylandXdgPoup that is processed (via wl_surface commit handling
etc) will have a parent_surface.
https://bugzilla.gnome.org/show_bug.cgi?id=771495
If a X11 client would initiate a Xdnd session after it had lost pointer
focus (for example when the Xdnd event starting the drag happens after
the implicit pointer grab is already broken due to the button being
released), just end the drag operation instead of dereferencing the
non-existing focus surface.
Also avoid using a native Wayland surface as a drag origin, as that can
never happen, but allow any arbitrary Xwayland client, since there is
no way to find out the actual drag origin.
https://bugzilla.gnome.org/show_bug.cgi?id=770940
