How to file a helpful issue
Qubes OS release
4.3
Brief summary
In 4.2 my custom "fullscreen" mode defined in I3 config, which allows to switch windows in fullscreen mode, was working properly. In 4.3 windows of some apps (Chromium, Discord, Teams for Linux) are not redrawn correctly when the parent container is using stacked/tabbed mode (window is not visible before switching to it).
The mode definition looks like this:
mode "fullscreen" {
bindsym $mod+f mode "default", fullscreen disable
bindsym $mod+h fullscreen disable, focus left, fullscreen enable
bindsym $mod+j fullscreen disable, focus down, fullscreen enable
bindsym $mod+k fullscreen disable, focus up, fullscreen enable
bindsym $mod+l fullscreen disable, focus right, fullscreen enable
bindsym $mod+1 fullscreen disable, workspace number $ws1, fullscreen enable
bindsym $mod+2 fullscreen disable, workspace number $ws2, fullscreen enable
bindsym $mod+3 fullscreen disable, workspace number $ws3, fullscreen enable
bindsym $mod+4 fullscreen disable, workspace number $ws4, fullscreen enable
bindsym $mod+5 fullscreen disable, workspace number $ws5, fullscreen enable
bindsym $mod+6 fullscreen disable, workspace number $ws6, fullscreen enable
bindsym $mod+7 fullscreen disable, workspace number $ws7, fullscreen enable
bindsym $mod+8 fullscreen disable, workspace number $ws8, fullscreen enable
bindsym $mod+9 fullscreen disable, workspace number $ws9, fullscreen enable
bindsym $mod+0 fullscreen disable, workspace number $ws10, fullscreen enable
}
bindsym $mod+f mode "fullscreen", fullscreen enable
I have already posted a discussion in the QubesOS forum: https://forum.qubes-os.org/t/i3-window-redraw-not-always-working-in-fullscreen/38628/4
And I3 disussion forum: i3/i3#6590 (reply in thread). Here I got a helpful answer suggesting some solutions to the problem. The only one that worked for me was to "postpone" the f"ullscreen enable" command by 0.1s. As this is not possible in the config file itself I decided to test this via a python script, which catches the bindings and executes the necessary commands via "i3-msg".
The person also mentioned some changes introduced in QubesOS 4.3 related to how window events are propagated in relation to Xen, which can be the reason for that problem
Steps to reproduce
- use I3 window manager
- add fullscreen mode into config file
- navigate to a tabbed/stacked application container
- open affected app (Chromium works most of the time, but gets stuck sometimes. Discord seems to be affected most of the time)
- enter fullscreen
- switch to next/previous window of the tabbed/stacked container
- sometimes windows are stuck and it is not possible to interact
Expected behavior
Switching windows for the above use case should work like it did in QubesOS 4.2
Actual behavior
Switching windows for the above use case causes them to get stuck (not being redrawn correctly)
Additional information
How to file a helpful issue
Qubes OS release
4.3
Brief summary
In 4.2 my custom "fullscreen" mode defined in I3 config, which allows to switch windows in fullscreen mode, was working properly. In 4.3 windows of some apps (Chromium, Discord, Teams for Linux) are not redrawn correctly when the parent container is using stacked/tabbed mode (window is not visible before switching to it).
The mode definition looks like this:
I have already posted a discussion in the QubesOS forum: https://forum.qubes-os.org/t/i3-window-redraw-not-always-working-in-fullscreen/38628/4
And I3 disussion forum: i3/i3#6590 (reply in thread). Here I got a helpful answer suggesting some solutions to the problem. The only one that worked for me was to "postpone" the f"ullscreen enable" command by 0.1s. As this is not possible in the config file itself I decided to test this via a python script, which catches the bindings and executes the necessary commands via "i3-msg".
The person also mentioned some changes introduced in QubesOS 4.3 related to how window events are propagated in relation to Xen, which can be the reason for that problem
Steps to reproduce
Expected behavior
Switching windows for the above use case should work like it did in QubesOS 4.2
Actual behavior
Switching windows for the above use case causes them to get stuck (not being redrawn correctly)
Additional information