Steps to reproduce:
1. Force the branch to be taken:
diff --git a/src/bindings.c b/src/bindings.c
index fe77bc8f..caa5848c 100644
--- a/src/bindings.c
+++ b/src/bindings.c
@@ -941,7 +941,7 @@ bool load_keymap(void) {
struct xkb_keymap *new_keymap = NULL;
int32_t device_id;
- if (xkb_supported && (device_id = xkb_x11_get_core_keyboard_device_id(conn)) > -1) {
+ if (0) {
if ((new_keymap = xkb_x11_keymap_new_from_device(xkb_context, conn, device_id, 0)) == NULL) {
ELOG("xkb_x11_keymap_new_from_device failed\n");
return false;
2. Run `python2 ./xproperty.py _XKB_RULES_NAMES ''` (from
https://github.com/siemer/xproperty) in the xinitrc
3. Memory sanitizers detect memory leaks.
Note: We don't (and didn't) pass NULL in xkb_keymap_new_from_names() but
an xkb_rule_names structures with NULL fields (fill_rmlvo_from_root only
fills its argument when there are no errors) should be equivalent:
767fa86d42/NEWS (L349-L351)
> The function xkb_keymap_new_from_names() now accepts a NULL value for
the 'names' parameter, instead of failing. This is equivalent to passing
a 'struct xkb_rule_names' with all fields set to NULL.
Fixes#2535.
Seems to be the intention, indicated by this comment (con.c:1307-1309):
/* For split containers, we use the currently focused container within it.
* This allows setting marks on, e.g., tabbed containers which will move
* con to a new tab behind the focused tab. */
Related to #3085.
xkb_state_new uses calloc and may fail in a rare case, which would cause a memory leak.
Note that xkb_state_unref checks if the parameter given is not null (!state) before freeing.
Calls to xkb_state_new have been grouped to remove code duplication.
Signed-off-by: Elouan Martinet <exa@elou.world>
con_next_focused uses con's parent. But since con can be inside an
unfocused container this means that one of it's siblings could become
focused in the current workspace.
The current_ws is shown latter anyway:
if (!ignore_focus) {
workspace_show(current_ws);
...
This also causes the following bug:
- Open a window in an empty workspace
- Switch to another workspace
- seturgent to the first window
- Move another window to the first workspace
- Urgent flag is now reset
This significantly reduces the number of ELOGs while dragging floating
containers. The behaviour is improved since floating containers in the
edge of the screen will still get reassigned to their closest workspace.
For example, consider this setup:
fake-outputs 500x500+0+0,500x500+500+0
Now, open a window in the right output and run:
i3-msg floating enable, move position 0 px 450 px
The window is on the bottom edge of the left workspace but if you run:
i3-msg focus mode_toggle
focus will go to the right workspace since floating_maybe_reassign_ws
didn't change the assigned workspace of the floating container.
This allows the floating container's top left corner to be mapped
outside any output as long as they are contained partially by one. This,
for example, will allow:
mpv --geometry +1+1 video.mp4
For windows mapped to (0, 0) see comment in floating.c:270-273:
/* Some clients (like GIMP’s color picker window) get mapped
* to (0, 0), so we push them to a reasonable position
* (centered over their leader) */
The floating_reassign_ws call is removed since we try to place the new
floating container in the current output:
/* Sanity check: Are the coordinates on the appropriate output? If not, we
* need to change them */
Fixes#1341
_NET_WM_STATE_FOCUSED is set on _NET_WM_STATE to indicate that the
window is focused. It must be set when the window is newly focused and
removed once the window no longer has focus.
> _NET_WM_STATE_FOCUSED indicates whether the window's decorations are
> drawn in an active state. Clients MUST regard it as a read-only hint.
> It cannot be set at map time or changed via a _NET_WM_STATE client
> message.
For example, this is used by GTK applications to show the decoration in
an active or inactive state. This change can be tested by opening a GTK
application (like evince), focusing the window and unfocusing the
window, and observing a change in the window decorations.
Fixes#2273
For command:
move window to [absolute] position X px Y px
if the optional keyword 'absolute' is provided the end result is the
same even though it is implemented differently. Only difference is that
with absolute the floating window can move completely outside of any
output.
This commit removes the 'method' argument and only keeps the sane
implementation.
With example config:
mode "a_mode" {
bindcode 27 --release mode "default"
}
bindsym $mod+r mode "a_mode"
The first time $mod+r is pressed "a_mode" is activated like normal. When
r (bindcode 27) is pressed to exit the mode:
- On the KeyPress event the corresponding bind->release is correctly
marked as B_UPON_KEYRELEASE_IGNORE_MODS.
- On the KeyRelease event the command 'mode "default"' is executed but
bind->release is still B_UPON_KEYRELEASE_IGNORE_MODS since they are only
reset on KeyPress events.
The second time $mod+r is pressed and "a_mode" is activated and when the
r key is released the 'mode "default"' is executed even though the mods
are not matching since bind->release == B_UPON_KEYRELEASE_IGNORE_MODS.
This still doesn't catch 2 cases:
1. When the order is: press $mod -> press r -> release $mod -> release
r. Since 'r' is released without any modifiers the binding matches.
2. With:
mode "resize" {
bindsym --release r mode "default"
}
bindsym r mode "resize"
This is arguably correct: on the KeyPress event we switch to the mode and
on the KeyRelease we switch back.
Before this commit, get_binding() exited on the first match without
marking the rest --release bindings with B_UPON_KEYRELEASE_IGNORE_MODS.
Similarly, once it found a --release binding during a KeyPress event it
would stop searching for a matching key press binding.
Example config, placing the --release line first will trigger the second
problem:
# i3 config file (v4)
bindsym Super_L exec notify-send "press"
# or
# bindcode 133 exec notify-send "press"
bindsym --release Super_L exec notify-send "release"
# or
# bindcode --release 133 exec notify-send "release"
Fixes#2733
From 548d74015c50d7fae14bfb8bb1989acde5fc22ae:
> 1. press $mod, press x, release x, release $mod
> 2. press $mod, press x, release $mod, release x
case (2.) didn't work, now it should be fixed.
When we run 'reload' all the assignments are freed:
e3e09119bf/src/config.c (L99-L109)
Assignments are saved to each window after they are executed:
e3e09119bf/src/assignments.c (L41-L46)
This means that the pointers stored in window->ran_assignments are
invalid (shouldn't be dangerous currently but could lead to a segfault
if the code is modified) after a 'reload'.
Fixes:
- Issue where moving an urgent (unfocused) window resets it's urgency
hint.
- Moving an unfocused container to a new parent should not move it to
the top of the focus stack.
This deals with (admittedly somewhat misbehaving) clients which
use XSetInputFocus to take focus, but then don't properly restore
focus. This has been observed with TK apps, but also, e.g., Steam.
fixes#2722fixes#3096
From comment:
https://github.com/i3/i3/issues/2990#issuecomment-368345169
To easily reproduce:
1. Open 2 floating windows
2. Focus (with `focus_follows_mouse`) the one behind
3. Move the mouse to the other workspace
4. Move the mouse inside the previous workspace (without it even
touching a window)
The problem here is that con_fullscreen_permits_focusing() does not
check if there is a blocking fullscreen container in the workspace that
the container to be focused belongs. This makes it possible to focus a
container behind a fullscreen window if it's in an unfocused workspace.
This commit introduces a change in the 'focus' command behaviour. When
focusing a container blocked by a fullscreen container, either CF_OUTPUT
or CF_GLOBAL, the blocking container loses its fullscreen mode and the
target container is focused like normal.
This should not affect directional focus commands: left, right, up,
down, parent, child.
Fixes issue #1819.
The bug triggers when _workspace_show calls tree_close_internal and
old == old_focus. Ie, when the old workspace was empty and needs to be
closed but then is accessed as output_push_sticky_windows's argument:
Breakpoint 1, output_push_sticky_windows (to_focus=0x55555589c8a0) at ../../i3/src/output.c:102
102 con_move_to_workspace(current, visible_ws, true, false, current != to_focus->parent);
(gdb) print con_exists(to_focus)
$1 = false
The access violation can also be prevented by checking if
con_exists(old_focus) but it shouldn't be necessary: the old_focus
container can only be killed when it is an empty workspace.
With --enable-sanitizers this causes i3 to exit but with
--disable-sanitizers the access violation doesn't reliably cause a crash
and the con_move_to_workspace call continues with:
(gdb) print current != to_focus->parent
$2 = 1
Since current->type is CT_FLOATING_CON and to_focus->type is
CT_WORKSPACE, in this specific case ignore_focus would always be true.
So, in this case, passing NULL instead of old_focus to
output_push_sticky_windows doesn't change the behaviour of i3.
Fixes#3075.
Prevents a false-positive error eg with config file:
set $mod Mod4
bindsym $mod+h split h
bindsym $mod+v split v
ERROR: CONFIG: Expected one of these tokens: <end>, '#', 'set ', ...
ERROR: CONFIG: Line 8: status_command i3status
ERROR: CONFIG: Line 9: }
ERROR: CONFIG: Line 10: <BE><BE><BE><BE><BE><BE>
With this change i3 will correctly switch to the focused workspace.
This fixes bug with moving floating windows with 'move <direction>' or by dragging like _NET_CURRENT_DESKTOP not getting updated or 'workspace back_and_forth' not working.
Fixes#2921.
i3bar's handle_button is modified to also handle XCB_BUTTON_RELEASE
events. During these button release events, only custom commands are
checked to avoid sending multiple workspace ipc messages.
The way this patch is implemented will allow to assign a custom command
for both the press and release of the same button:
bar {
...
bindsym buttonX exec command1
bindsym --release buttonX exec command2
}
Fixes#3068.
Issue #3049 describes a case where terminating i3 by means of SIGTERM
causes it to leak the runtime directory and all its contents. There are
multiple issues at play: first, any cleanup handlers registered via
atexit are never invoked when a signal terminates the program (see
atexit(3)). Hence, the log SHM log cleanup performed in i3_exit is not
invoked in that case. Second, compared to the shutdown path for the
'exit' command, we do not unlink the UNIX domain socket we create,
causing it to be leaked as well. Third, a handler for SIGTERM is not
registered at all despite handle_signal claiming to be the handler for
all 'Term' signals.
This change addresses all three problems and results in a graceful exit
including cleanup to happen when we receive a signal with the default
action 'Term'. It addresses issue #3049.
Previously, we used ev_check watchers, which are executed at the beginning of an
event loop iteration.
This was problematic if one of the handlers happened to fill the XCB event
queue, e.g. by reading a reply from X11 and an event happened in the meantime.
In that situation, we would hand control to the event loop, entirely ignoring
the pending event. This would manifest itself as a 1-minute hang,
reproducible (sometimes) in the i3 testsuite.
issue #2790 describes an instance of this issue in i3bar, and we fixed that by
changing the watcher priority to run last. Handling events in xcb_prepare_cb has
the same effect, as ev_prepare watchers are run just before the event loop goes
to sleep.
The sender of the _NET_ACTIVE_WINDOW client message might know better when to
set focus than i3, as i3 does not know about unmanaged (override_redirect=1)
windows.
related to https://github.com/i3/i3lock/issues/35
stbuf.st_size is of type off_t, which the standard defines as “extended signed
integral type”¹, and for which there is no correct printf format string. Hence,
we need to cast it into a hopefully-large-enough type (ugh) and use the
corresponding format string. In our case, int64_t should do it, as config files
really shouldn’t be anywhere close to those numbers.
① http://pubs.opengroup.org/onlinepubs/007908799/xsh/systypes.h.html
This way, when changing focus between outputs, the directional focus
command will focus the focused window within the parent container that
is next in the given direction.
Previously, the next window of the given direction was focused which is
Inconsistent with changing focus inside the same output.
Fixes#1160.
Orestis Floros