fbce834b introduced a bug where scrolling over the decoration while
another container is focused would not focus the tabbed/stacked
container itself, but would instead move focus through the currently
focused container.
When moving a workspace to the current output by way of a rename, if the
current workspace is empty, it will be removed by `workspace_show`.
Attempting to restore focus to this removed workspace causes a crash.
Follow the pattern in workspace.c:996 to only restore the original focus if the
original workspace still exists.
Add a test to ensure that the renamed workspace moves to its appropriate
output and that a crash does not occur.
Fixes#3228
When we don't modify the focus we aren't risking giving focus to a
container behind the current fullscreen one.
_con_move_to_con can with ignore_focus is called through the swap
command or through con_move_to_workspace for floating containers. This
change shouldn't break the expectations of the callers there.
Fixes issue #3259.
- 'border toggle' now accepts an optional pixel argument which will be
ignored when switching to BS_NONE.
- 'border pixel' now defaults to 1 pixel instead of 2.
- Calling 'border normal' or 'border pixel' will use the configured
default_border_width if one exists. Also applies to floating windows.
Fix the issue #3227(https://github.com/i3/i3/issues/3227).
1).Make cmd_scratchpad_show() use the information coming from scratchpad_show().
2).Add a test case 298-scratchpad-show.t.
Was a small typo.
This also has the (positive) side-effect of allowing to move all the
content of a marked workspace next to the target container, see added
tests.
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.
Ingo Bürk