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'.
Before:
$ i3-msg floating disable, move window to position 100 px 100 px
ERROR: Your command: (null)
ERROR: (null)
ERROR: Cannot change position of a window/container because it is not floating.
[{"success":true},{"success":false,"error":"Cannot change position of a window/container because it is not floating."}]
After:
$ i3-msg floating disable, move window to position 100 px 100 px
ERROR: Cannot change position of a window/container because it is not floating.
[{"success":true},{"success":false,"error":"Cannot change position of a window/container because it is not floating."}]
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.
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)