I have experienced an odd issue while working with qubes 4.1 - though I have posted this in general user support because I do not know the scope of the issue.
My applications seem to “freeze” up and become unresponsive sometimes. I am not saying the applications itself, but more of the window that the application is in. For instance, I will be in something like VS code when suddenly my typing stops working. The only reliable way to get the window to respond to changes again is to switch my view to another window, and back to my desired location.
I am curious if others have ran into this same issue while on 4 or 4.1. Something to note: I am using the “new application menu” but I highly doubt this is the root cause of the problem.
I find the talk of “freezing” interesting (there have been other posts referring to system freeze before now) & I considered posting the following (see inset) but frankly I suspect that it may only add to our confusion so it shall remain as a tiny artifact attached to the idea:
I’m not going to say much about this matter but here’s a posit & an open question. Does anyone here using (doesn’t apply to previous graphical systems under Qubes used in 4.0.4 & before - think “sys-GUI or whatever form is used on installations of 4.1rcx” since I’m still rocking a couple rcs that I just haven’t bothered to actually re-install from scratch & which may count as non-rc now naturally or maybe not) the current version of Qubes notice that if they have two or more windows open under a given VM (an AppVM like personal for instance) that from time to time the graphical experience (the window management portion or whatever is responsible) seems to become confused about which window the mouse or keyboard operations ought to be receiving the activity a user is performing? Because the few times that I have had something similar to this “freezing” it was under such a situation on one of my rc systems (but not under my still 4.0.4 systems). It only took comparative analysis to see how the system wasn’t truly froze & that guessing towards a solution allowed me to get back some measure of control but I haven’t tried to replicate the issue. I do not have a ton of details about this nor the capability to play around to see about it, but it definitely stuck out like a sore thumb at the time. It happened on systems that I have periodically used for update purposes & limited testing & this event was singular & not preceded or followed by anything noteworthy.
As far as I know the problem lasts from R3.2 to R4.1; VSCode often witnesses the problem, then Google Chrome and other apps; Avoid minimizing windows may help since window minimization in dom0 is not known by appVM.
Basically I think that dom0 and appVM disagree on which window is focused.