Currently when renaming outputs, an output assignment of "left" will
cause the workspace to move left. Treat this assignment as a proper name
instead (even though it is unlikely an output will be named "left").
Move logic for determining output to move to out of
`workspace_move_to_output`
Add test for ignoring direcionality during rename.
Fixes#3208.
The current behaviour is buggy in the following layout:
T [ A* V [ B C ] ], where the focus stack in V is B > C.
When the user scrolls down, focus correctly moves to B but if the user
scrolls down again the whole vertical container is focused.
This happens because 'bool scroll_next_possible' is false but
con_activate is called on the tabbed container's sibling - the vertical
container.
Explanation for the changed test:
After $third is switched to floating, the test moves focus to $second.
So, the parent of $second (the stacked container) is above $third in the
focus stack and it's children ($first, $second) should get focused
before $second. When $second is switched to floating the correct focus
order for the workspace should be $second->parent (floating con is the
parent) > $first->parent (stacked con) > $third.
Fixes#1975
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.
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.
_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
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.
Remove the assumption that only two atoms can possibly be set in
t/253-multiple-net-wm-state-atoms.t so that the tests will pass when
more atoms are supported that may be set during this test.
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.
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.
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.
We need to set dont_map => 1 on the sync window to prevent an endless loop.
Further, t/219-ipc-window-focus.t made assumptions about windows being named
incrementally, and that assumption is broken by the sync window opened by the
first sync_with_i3 call from open_window, so use the more reliable ->name.
1). Add one regression test in 167-workspace_layout.t:
- Get a fresh workspace
- Set the layout to something
- Create windows
- Try to switch to another layout
- Check if successful
- Repeat for all 12 possible transitions
2). Add another regression test in 167-workspace_layout.t:
- Check that the command 'layout toggle split' works regardless of
what layout we're using
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.
Applied for:
1. '[...] focus' for a floating container raises it to the top.
2. Focusing a window through a focus event raises it to the top.
Fixes#2572
canonicalize_output_name allowed the "primary" special output name to
be canonicalized, thus converting it to the name of whatever output
was the primary output at the time. This caused settings
(specifically, i3bar output and tray_output settings) to be stored as
specific output names, instead of the intended special names whose
referred output may change as the system's configuration (i.e. current
primary output) changes.
Add a check to canonicalize_output_name to return the name as-is if it
is the special name "primary".
This fixes a regression introduced in commit
4e88c10564ca5366c2578908f62ec56625a26718: when attempting to move the
single child of a container in the direction of another output, i3
would move the window to the output, despite the window not being at
the edge of its output, instead of moving it to its parent container.
The bug occurred because the check for moving containers across
outputs with non-default workspace layouts (issue #1603) did not
actually verify that the moved window lies at the edge of the
workspace, despite what its comment said.
Fixes issue #2466.
Makes "assign [<criteria>] workspace number <number>" work in the same
manner as "move to workspace number <number>" instead of assigning the
window to a workspace named "number <number>".
config.spec is modified to expect a 'number' string and an extra
argument is used in cfg_assign.
For workspaces that don't exist yet, workspace_get is used as a
fallback. This also allows the user to assign to "<number> <workspace>"
eg "2: work" and the full name will be used if workspace number 2
doesn't exist yet.
Fixes#2590.
This way you can assign the test windows to an empty workspace to avoid
interacting with them (when xvfb-run is not an option):
assign [instance="i3test"] workspace testing
I previously tried to fix the check, but could only come up with a fix which
required removing our module pre-loading, which makes the tests considerably
more expensive. Instead, let’s just remove the check.
The test runs `xrandr setmonitor`, which will otherwise affect any test
scheduled after 533-randr15.t, causing flakyness in t/217-NET_CURRENT_DESKTOP.t
for example.
Oliver Graff