handle_tool_tip() previously used event->tool->data without checking
for NULL. When launching sway for the first time after a reboot, and
then tapping with a USI 2.0 stylus, the tool tip event is fired before
the tool proximity event. As event->tool is initialized during the tool
proximity handler handle_tool_proximity(), this was causing a crash.
The fix adds a NULL check before accessing the fields of
event->tool->data. In case of a NULL, a log message is emitted
indicating that the tool tip event fired before proximity. This logic is
identical to the logic in handle_tool_axis().
Fixes issue #8907
Closing a tiled window (mod+shift+q) while resizing (mod+click) causes
an use-after-free in handle_unref.
Both conditions can be true in this case, which will result in
dereferencing `e` on the second check after it has already been freed by
the first `seatop_begin_default`.
Fix by combining separate checks for the main container and its
horizontal/vertical siblings into a single condition.
The second check was added in 9e272a7986
and I've checked that this fix does not regress that issue.
I misunderstood the recommendation in the libinput release notes.
Instead of making enabled_sticky the default, leave the default
set to disabled.
Fixes: bbadf9b8b1 ("Add support for LIBINPUT_CONFIG_DRAG_LOCK_ENABLED_STICKY")
Closes: https://github.com/swaywm/sway/issues/8758
Unfocused windows shouldn't be allowed to activate the IM.
This fixes an issue with swaymsg invocations that contain several
commands which result in multiple swift focus changes. An application
briefly gets text input focus, sends an enable request, then sway
processes it and activates the IM only after the commands are all
finished and focus is on something else which did not send an enable
request.
sway_input_method_relay can be destroyed from two sources, either the
seat is destroyed or the manager protocol objects are destroyed due
compositor exit.
This fixes a crash in wlroots listener checks. See #8509.
in the origin text_input.c, we only check the sway_view and layershell,
but now we have the third shell named sessionlock, so we need to modify
both text_input.c and view.c to handle the new type of shell
When handling a button click with one or more modifiers, or using the
mouse with the floating modifier, assume that the modifiers are not
intended as a standalone keybinding, and clear the held_binding from
the keyboard. This way it is possible to use a single modifier (e.g.
Super) as main modifier, floating modifier, and as a standalone
keybinding (with --release). Fixes#4505
switching workspace directly to urgent window creates timer which delays
reset of urgent state so user is able to notice it. make sure state
change is reflected visually as well (border change) by triggering
container update
Fixes: #8377
Man sway(5) specifies that when tiling_drag is enable, the floating_mod
can be used to drag tiling, as well as floating containers. However the
current code indiscriminately assumes any button press to be intended
for moving the container, consequently causing an unintended call to
`seatop_move_tilting:handle_button` rather than
`seatop_default:handle_button` to pass
`state=WL_POINTER_BUTTON_STATE_RELEASED` to `get_active_mouse_binding`
My idea was to make 'Handle moving a tiling container' follow the same
path as 'Handle moving a floating container' because the initial call to
handle moving a floating correctly exits that branch and ends up passing
the RELEASED state to `get_active_mouse_binding`.
Fixes#8334
in pr https://github.com/swaywm/sway/pull/8196, when im_popup_surface is unmapped, author set the popup->relative to NULL, butt popup is still in popup groups, where assert the relative is not NULL, this cause the panic
Take the suggestion of Nefsen402, remove the line where set relative to
NULL, and add NULL check in scene_descriptor_destory
Previously, we incorrectly only set active keyboard for non-virtual
devices. 4c3c060211 incorrectly put
unrelated code in `sway_keyboard_set_layout`.
Fixes: 4c3c060211
"The compositor must not send this event if the wl_keyboard did not
have an active surface immediately before this event. The compositor
must not send this event if state is pressed (resp. released) and the
key was already logically down (resp. was not logically down)
immediately before this event."
From https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/382
The only reason it's included there is for a declaration of
struct sway_server, but we can just forward-declare it.
This avoids rebuilding almost all of Sway when touching server.h.
All other server.h includes are from source files, not headers.
Instead of having a build-time option to enable/disable xwayland
support, just use the wlroots build config: enable xwayland in
Sway if it was enabled when building wlroots. I don't see any
use-case for disabling xwayland in Sway when enabled in wlroots:
Sway doesn't pull in any additional dependency (just pulls in
dependencies that wlroots already needs). We have a config command
to disable xwayland at runtime anyways.
This makes it so xwayland behaves the same way as other features
such as libinput backend and session support. This also reduces
the build matrix (less combinations of build options).
I think we originally introduced the xwayland option when we didn't
have a good way to figure out the wlroots build config from the
Sway build system.
