The crash only occurs if the mouse cursor is above the tabbed container
when the last child is closed.
Introduced in 03d49490cc, over a week ago
and unnoticed until now :O
The above commit changes the behaviour of a focus change. When you
change focus, it sends pointer motion which makes the client set a new
cursor image. We already had this behaviour for workspace switching, but
this commit adds it for view switching too, such as in a tabbed
container or when closing a view.
The sequence of events that leads to the crash is:
* The last child of a tabbed container unmaps, which triggers a
`destroy` event before we've cleaned up the child or reaped the tabbed
container.
* The seat code listens to the `destroy` event and removes the seat
container from the focus stack. As part of this, it decides to set focus
to the parent (my fix alters this decision).
* When setting focus to the new parent, the container motion is sent as
per the previously mentioned commit.
* The motion code uses `container_at`, which encounters the tabbed
container and its child in a half destroyed state, and everything blows
up from there.
`con->parent` is needed because scratchpad containers don't have parents
if they're hidden, so this probably fixes a crash when a hidden
scratchpad container closes too.
The `con->parent->children->length > 1` check should catch any cases
where the parent is about to be reaped.
This makes it so if you hold mod and right click on a surface to resize
it, the resize direction is chosen based on which quarter of the surface
you've clicked. The previous implementation only resized towards the
bottom right.
The mouse binding logic is inspired/copied from the
keyboard binding logic; we store a sorted list of the
currently pressed buttons, and trigger a binding when
the currently pressed (or just recently pressed, in
the case of a release binding) buttons, as well as
modifiers/container region, match those of a given
binding.
As the code to execute a binding is not very keyboard
specific, keyboard_execute_command is renamed to
seat_execute_command and moved to where the other
binding handling functions are. The call to
transaction_commit_dirty has been lifted out.
First, the existing sway_binding structure is given an
enumerated type code. As all flags to bindsym/bindcode
are boolean, a single uint32 is used to hold all flags.
The _BORDER, _CONTENTS, _TITLEBAR flags, when active,
indicate in which part of a container the binding can
trigger; to localize complexity, they do not overlap
with the command line arguments, which center around
_TITLEBAR being set by default.
The keyboard handling code is adjusted for this change,
as is binding_key_compare; note that BINDING_LOCKED
is *not* part of the key portion of the binding.
Next, list of mouse bindings is introduced and cleaned up.
Finally, the binding command parsing code is extended
to handle the case where bindsym is used to describe
a mouse binding rather than a keysym binding; the
difference between the two may be detected as late as
when the first key/button is parsed, or as early as
the first flag. As bindings can have multiple
keycodes/keysyms/buttons, mixed keysym/button sequences
are prohibited.
cursor_set_image only uploads the named image if it doesn't match the
previous named image. This means when setting the cursor image to a
surface as given by a client, we have to clear the currently stored
image.
Implements the following commands:
* move scratchpad
* scratchpad show
* [criteria] scratchpad show
Also fixes these:
* Fix memory leak when executing command with criteria
(use `list_free(views)` instead of `free(views)`)
* Fix crash when running `move to` with no further arguments
This allows to update the title even if the view doesn't commit.
This is useful e.g. when a terminal sets its toplevel title to
the currently running command and when the view isn't visible.
Also does a few other related things:
* Now uses enum wlr_edges instead of our own enum resize_edge
* Now uses wlr_xcursor_get_resize_name and removes our own
find_resize_edge_name
* Renames drag to move for consistency
When interactively resizing some views (eg. Nautilus), new transactions
are added to the queue faster than the client can process them.
Previously, we would wait for the entire queue to be ready before
applying any of them, but in this case the transactions would time out,
giving the client choppy performance.
This changes the queue handling so it applies the transactions up to the
first waiting transaction, without waiting for the entire queue to be
ready.