Windows that set empty input shapes get n_rects of 0 when querying them
later, which makes sense, but the code that interpreted the result
translated it into a NULL input shape, which meant it was the same as
the bounding region. As such, an empty input shape would actually get
interpreted as a full input shape!
We, ourselves, set an empty input shape on tray icon windows in
gnome-shell since we would handle the picking ourselves. This meant that
we'd actually get the MetaSurfaceActorX11 when hovering over the tray
icon, instead of the ShellGTKEmbed that we capture events on and react
to.
This fixes weird tray icon behavior in gnome-shell.
We clip the input region to the client rect, so the client rect should
be up to date before we fetch the input region.
This fixes popup windows not working in GTK+2 under Wayland.
We should also update the shape / input regions when the window is
reconfigured for a complete fix, so that making an O-R window bigger
doesn't confuse mutter, but let's leave that to a future commit.
The coordinates in ConfigureNotify *should* be the coordinates of the
client window; using the coordinates of the frame window compensated for
a problem with the interpretation of StaticGravity for some clients but
broke other clients.
This reverts commit f4f70afe31.
https://bugzilla.gnome.org/show_bug.cgi?id=736719
This prevents issues from happening when processing Enter/Leave events
while in another kind of grab op like a Wayland popup or resizing a
window.
This can't ever really happen except outside of a race condition,
with the X server, since we won't ever pass input events to the
X server in any of these cases, but it can't hurt to be more correct
about what the intended operation is.
GTK+ focuses its own windows with RevertToParent, which means that when
a GTK+ CSD window is destroyed, the X server will set the focus back to
the root window. The event stream that we is an UnmapNotify followed by
a FocusOut event. Our own UnmapNotify-handling code unmanages the window
and forcibly changes the focus to the next default window in the stack.
Since UnmapNotify events don't come with timestamps, we query for one,
and set the window focus using that.
But there's *still* a FocusOut event in the stack, with an older
timestamp and serial than our own focusing. We see this, throw it out
since it's older than the most recent focus, but then our own code that
notices the root has been focused kicks in and tries to focus the
default window... using a timestamp older than our most recent focusing.
meta_display_sanity_check_timestamps notices this, and (rightly so)
puts a warning in our face, telling something is awry.
Only let our workarounds kick in when the event is new enough, otherwise
our code will get confused over old events.
This stops the:
Window manager warning: last_focus_time (367917173) is greater than comparison timestamp (367917170). This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW. Trying to work around...
warning spam when closing a CSD window.
The merge of the commit af46ef3b 'meta_window_new: clean up error handling'
to the wayland branch accidentally added an extra call to meta_error_trap_push(),
meaning that we leaked one level of error traps for each new window.
Fixes warning:
Gdk-WARNING **: XSetErrorHandler() called with a GDK error trap pushed.
https://bugzilla.gnome.org/show_bug.cgi?id=736589
When the screen resizes, we get a configure event for the composite overlay
window - don't pass that to MetaStackTracker, since the COW isn't in the
stack.
Fixes warning:
mutter-WARNING **: STACK_OP_RAISE_ABOVE: window 0x65 not in stack
Add a private hook for the test framework to get XSyncAlarmEvent events -
this will be used to implement XSyncCounter based synchronization
so that the test framework can deterministically wait until Mutter
has seen actions performed by an X11 client.
https://bugzilla.gnome.org/show_bug.cgi?id=736505
Before, we were using the root window coordinates of the client window,
rather than the toplevel frame window. This caused various Java programs
and programs like VirtualBox and WINE to get confused about where their
window actually is, and make bad ConfigureRequests when trying to
position their windows in the future.
Remove the mass of code here by just using window->rect.
The existing workspace management code is quite hairy, with plenty of
logic inline in all of window.c, workspace.c, and screen.c, making it
hard to understand or make changes to, since you might forget to change
several of the other places the code was around.
Rewrite the internal workspace management logic so that it's
centralized and all in window.c. Document the invariants we need to
maintain, and ensure that these invariants are properly kept, with
asserts in various places.
Extensive testing on gnome-shell did not bring up any issues, and this
is a considerable cleanup.
Since commit 467465c99c we use meta_stage even on x11 which sets
clutter_stage_set_user_resizable to FALSE.
This messes things up because we ought to ignore the properties on the window
but we apperently didn't.
There is no reason why we'd want to manage the stage window.
https://bugzilla.gnome.org/show_bug.cgi?id=734852
Since commit a7b7213017, we rely on the standard property
system to initialize the window type (and likewise for the window
role since commit 031154a400). However as property hooks are
never run for properties that are not set, we end up not initializing
the window type correctly for windows with no _NET_WM_WINDOW_TYPE
property (which includes virtually all OR windows, causing them to
show up in pagers and the Shell overview and resulting in frequent
crashes due to breaking reasonable assumptions all over the place).
Introduce a new FORCE_INIT flag to allow forcing hooks to run
even when the corresponding property is unset, and use it for
both _NET_WM_WINDOW_TYPE and _NET_WM_WINDOW_ROLE.
This is so we won't poke into the MetaDisplay, which is invalid memory,
and crash. This can sometimes work right now because GSlice might not
deallocate the object immediately, but it's still not a fun thing to do.
Properties like _NET_WM_DESKTOP and _NET_WM_STATE are supposed to be
ignored after the initial map of the window, so ignore any
PropertyNotifies for these.
