sway, in terminal characters printed if focus switched immediately

[vvrein]

Hi! Recently I've wrote about problems with newlines printed in terminal, after swaymsg focus left executed. Video: https://tort.icu/bin/raw/k55mtgkq.mp4 https://github.com/swaywm/sway/issues/4975#issuecomment-633006519

But @RedSoxFan said that

I thought we already sent key release events on focus change. https://github.com/swaywm/sway/issues/4975#issuecomment-633134511

So this gave me the idea that newlines is not related to the sway itself.

First part - zsh's preexec,precmd

Further investigations resolved this question for a half:
The problem is in zsh's add-zsh-hook -Uz preexec command.
This command adds possibility to execute command before execution command in prompt.

When I commented out all lines with add-zsh-hook -Uz preexec or add-zsh-hook -Uz precmd or any sourced files with preexec|precmd in it like source /usr/share/zsh/plugins/zsh-autosuggestions/zsh-autosuggestions.zsh

-- problem gone.

But, when I have tried to record this behaviour, with and w/o preexec|precmd in .zshrc - I've found that with wf-recorder running newlines are always printed...

Second part - congestion

Further investigations makes me a little confused...

Without swaymsg

The first one -- I was able to reproduce this behavior without issuing swaymsg command at all.
The second one -- I was able to reproduce this behavior in bash, while I thinked that this is only zsh related issue.

Reproducing steps

I've typed: imv & Then bring imv to foreground -- fg, which, after pressing Enter, spawns imv window and switches focus immediately to it. Then I wait some time, press q, which get me back to previous window, where fg was typed.

zsh

zsh imv terminal listing

```shell 12:53:29 S 0 vrein@tokk:~ | imv & [1] 68131 12:53:33 S 1 vrein@tokk:~ | Reading paths from stdin... [1] + suspended (tty input) imv 12:53:33 S 1 vrein@tokk:~ | fg [1] + continued imv 12:53:38 S 0 vrein@tokk:~ | imv & [1] 68184 12:53:42 S 1 vrein@tokk:~ | Reading paths from stdin... [1] + suspended (tty input) imv 12:53:42 S 1 vrein@tokk:~ | fg [1] + continued imv 12:53:43 S 0 vrein@tokk:~ ```

White-spaces here was typed while imv window was focused.

bash

Reproducing of this behavior in bash with such setup:

• sudo cpupower frequency-set -g powersave
• stress -c 12 (all my threads)
• wf-recorder -f dummy-vf.mp4

wf-recorder somehow loads my pc more, so newlines printed behavior occurs more often

bash imv terminal listing

```shell 13:16:04 S 0 vrein@tokk:~ | bash 13:16:07 S 0 vrein@tokk:~ | imv & [1] 69951 13:16:09 S 1 vrein@tokk:~ | Reading paths from stdin... [1]+ Stopped imv 13:16:10 S 1 vrein@tokk:~ | fg imv 13:16:12 S 0 vrein@tokk:~ | 13:16:12 S 0 vrein@tokk:~ | imv & [1] 70025 13:16:19 S 1 vrein@tokk:~ | Reading paths from stdin... [1]+ Stopped imv 13:16:20 S 1 vrein@tokk:~ | fg imv 13:16:22 S 0 vrein@tokk:~ | imv & [1] 70125 13:16:33 S 1 vrein@tokk:~ | Reading paths from stdin... [1]+ Stopped imv 13:16:34 S 1 vrein@tokk:~ | fg imv 13:16:36 S 0 vrein@tokk:~ | 13:16:36 S 0 vrein@tokk:~ | 13:16:36 S 0 vrein@tokk:~ | 13:16:36 S 0 vrein@tokk:~ | 13:16:36 S 0 vrein@tokk:~ ```

Here you can see, that several attempts was needed to reproduce this.

Thoughts

Aaaand so, main consistent pattern is: The more

• bells and whistles in shell is configured
• more pc loaded

the more consistent this glitch is

And I wasn't able to reproduce this with shell started like this:

• bash --norc
• env ZDOTDIR='' zsh

So I think, main problem is in immediately focus switching, after Enter have been pressed so key release

• does not sent?
• delayed sent until focus back?
• sent to newly focused window?
• shell is too busy for accepting it?

But I still do not understand what kind of problem it is, and whose it is.

I can bring log of env WAYLAND_DEBUG=1 <terminal> a little later, if needed.

My setup

$ swaymsg -t get_version
sway version 1.4-2a2dd580 (May 23 2020, branch 'master')

$ lsmod | grep nvidia | wc -l
0

$ grep 'model name' -m 1 /proc/cpuinfo
model name  : AMD Ryzen 5 3600 6-Core Processor

$ lspci | grep VGA
08:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X] (rev c7)

[vvrein]

Bash reproduces 100% time, with bash-preexec

$ wget https://raw.githubusercontent.com/rcaloras/bash-preexec/master/bash-preexec.sh
$ . bash-preexec.sh
$ preexec() { echo "just typed $1"; }
$ swaymsg focus right
<Mod+Left>

bash swaymsg terminal listing

```shell 06:27:47 S 0 vrein@tokk:~ | swaymsg focus right just typed swaymsg focus right 06:30:35 S 0 vrein@tokk:~ | 06:30:35 S 0 vrein@tokk:~ | 06:30:35 S 0 vrein@tokk:~ | 06:30:35 S 0 vrein@tokk:~ | 06:30:35 S 0 vrein@tokk:~ | 06:30:35 S 0 vrein@tokk:~ | 06:30:35 S 0 vrein@tokk:~ | 06:30:35 S 0 vrein@tokk:~ | 06:30:35 S 0 vrein@tokk:~ | 06:30:35 S 0 vrein@tokk:~ | 06:30:35 S 0 vrein@tokk:~ | 06:30:35 S 0 vrein@tokk:~ | 06:30:36 S 0 vrein@tokk:~ | swaymsg focus right just typed swaymsg focus right 06:30:36 S 0 vrein@tokk:~ | 06:30:37 S 0 vrein@tokk:~ | 06:30:37 S 0 vrein@tokk:~ | 06:30:37 S 0 vrein@tokk:~ | 06:30:37 S 0 vrein@tokk:~ | 06:30:37 S 0 vrein@tokk:~ | 06:30:37 S 0 vrein@tokk:~ | 06:30:37 S 0 vrein@tokk:~ | 06:30:37 S 0 vrein@tokk:~ | 06:30:37 S 0 vrein@tokk:~ | ```

[vvrein]

Below is my default zsh setup with preexec|precmd sway version 1.4-f7f7179f (May 25 2020, branch 'master')

Also, any key press is repeated (look screenshot) After wf-recorder was stopped -- this glitch happens only once

screenshot zsh wf-recorder swaymsg focus right


---

Next, seems this only reproduces, if original surface becomes invisible after key pressed, since I couldn't reproduce this with swaymsg focus floating

screenshot zsh wf-recorder swaymsg focus floating


[vvrein]

And I wasn't able to reproduce this with shell started like this:

• bash --norc
• env ZDOTDIR='' zsh

UPD: wf-recorder fixed this :smile:

Shots

  

[vvrein]

And so, it more and more begins to look like it’s a problem in the “race condition” or “processor speed” or something related to loading the PC. If I imagine correctly, this needs to be fixed in the low-level asynchronous (?) code, which may be complicated. Regarding this, question come up:

• Does this intended to be fixed? Since bug comes out only in rare conditions. (But maybe there is other situations that I don't met.)