Active window does not receive focus #434

In the past few days I've been hit by a new bug in TDE. The bug manifests by the active window not receiving focus. Here's what it means exactly:

TDE is fully responsive to any mouse commands.
If a window is active it does not receive focus. It means that the top window bar is greyed out and the window does not receive any keyboard input.
However, global keyboard inputs continue to work. For example, I have F12 assigned to open Yakuake console. And so pressing F12 opens Yakuake window, but it does not accept any keyboard input. I can Ctrl-Alt-F1 to switch to text terminal. I can Alt-Tab to other windows, though there is a slight change in behaviour of the Alt-Tab window. If I hold Alt and press Tab once it opens the window list with the first window highlighted. Under normal circumstances the second window on the list would be highlighted. In other words, in order to switch to the previous window I need to press Tab twice, not once as is usual.

This bug persists until I log out of TDE session. I have not yet identified what triggers the bug, but inactivity seems to play a key factor here. I suspect this being somehow related to the screensaver. I will keep experimenting to see if I can discover anything.

I am attaching a screenshot of Konqueror window. The window is fully responsive to mouse input, but as you can see the bar with the window title is grey and the window does not respond to any keyboard input.

I am also attaching my aptitude log from November. I believe the bug was introduced by one of the upgrades in the final days of the month, and so it should be read from the end. You'll notice that the last update on the 30th of November update the screensaver packages, which coincides with my suspicion that inactivity and the screensaver could be at fault here. I will continue monitoring this.

I am labeling this as major, since it significantly impacts TDE usability, forcing several session logouts during a single day.

tde-bug2.png

105 KiB

aptitude.log

56 KiB

Hi Janek,
@SlavekB and I have noticed this too and we are trying to find out the root cause. Slavek also mentioned the screensaver. I don't use screensaver but being a VM I ofter suspend it to disk externally (as in I suspend the host).
I experienced this once about 10 days ago, Slavek has experienced this more ofter.
There are some obvious changes made to twin recently, so they will be the first things looked at, but for a few more days we are trying to figure out what triggers this behavior.

As a temporary remedy, I suggest you type

twin --replace

including the empty second line in an open editor and keep it handy. If the problem persists, copy the text (including the new line) and paste it into a Konsole window and it will restart twin without having to logout.

"Major" is perfect.

I have disabled the screen saver in hope to prevent the bug from happening but it doesn't seem to help. I had the bug just happen on me when I was printing documents from KPDF, right after clicking the "Print" button in the printing dialog.

So, even if the screen saver can cause the problem it is not a necessary condition.

Also, the temporary remedy does not work for me. Running twin --replace results in a bunch of errors (one lengthy permissions error and something about TDELauncher not being available via dcop) and the end result is no keyboard inputs and no window decorations.

Also, the temporary remedy does not work for me. Running twin --replace results in a bunch of errors (one lengthy permissions error and something about TDELauncher not being available via dcop) and the end result is no keyboard inputs and no window decorations.

Are you running it from the session that is affected by this problem? I watched the problem again a little while ago and running twin --replace & again works for me.

Are you running it from the session that is affected by this problem?

Yes. I saved this as a bash script and when the problem happens I run it from Konqueror menu Tools -> Execute shell script.

Maybe try DISPLAY=:0 twin --replace &? This makes the display explicit.
This should probably work even if you open a separate CLI session

I managed to get the workaround to work. Apparently, putting the command into a script was the cause of problems. I have now assigned twin --replace & to a global shortcut Win+Alt+F6 via TCC and this correctly restarts twin when the bug occurs.

putting the command into a script was the cause of problems.

I guess the script is run in an environment that is missing some variables.
Good idea for the shortcut.
Are you able to replicate the bug systematically? I only experienced it once and since then no problem.

I don't have a method of replicating the bug systematically, but it happens frequently (twice in the last hour, multiple times in a single day). It seems to be triggered by switching or closing windows? I'm not even sure of that.

In future can you try to pay attention to what action you were doing when this happens? Like closing or switching window, whether it is a particular application or anything that could be useful?

Are you on PSB, PTB or R14.1.1? if PSB, do you have the very latest packages installed?

In future can you try to pay attention to what action you were doing when this happens? Like closing or switching window, whether it is a particular application or anything that could be useful?

I'm trying, but unfortunately I'm not seeing any pattern. At first I thought this only happens when closing a window, but since then I've seen it happen when switching windows and even when switching tabs in Konqueror.

I'm on PSB (R14.1.2~[DEVELOPMENT]) and I have the latest packages.

Could you try a quick test?
Install twin-trinity from R14.1.1 (you may need to force this), reboot and see if the problem goes away. At least it will give some indication whether the problem is triggered by recent twin changes or not.

What's the repo address for the stable builds for Bookworm?

deb http://mirror.ppa.trinitydesktop.org/trinity/deb/trinity-r14.1.x <your-distribution-release-name> main deps

# Optional sources
deb-src http://mirror.ppa.trinitydesktop.org/trinity/deb/trinity-r14.1.x <your-distribution-release-name> main deps

Downgraded to R14.1.1. If the bug happens again I'll let you know.

Packages with reverted patch a9bd5b50e9 will soon be available in the repository. This patch is suspected of being the cause of the problem. Once you test the behavior with R14.1.1, you will be able to update and take the next step in tests.

Let me spend a day or two using the R14.1.1 package and then I'll test the updated one.

Let me spend a day or two using the R14.1.1 package and then I'll test the updated one.

Good idea.

Downgraded to R14.1.1. If the bug happens again I'll let you know.

Did you downgrade only twin-trinity or all tdebase?

Just two packages: twin-trinity and tdebase-trinity.

Just two packages: twin-trinity and tdebase-trinity.

Ok thanks. How is it looking so far?

No crashes so far.

Then maybe try the patched package from PSB? That would give valuable feedback to us

Installed now. I'll let you know if it crashes.

Happening here too. I'm glad it's not just me.

A couple of additional pieces of info:

As far as I can tell, it has nothing to do with the screensaver. It happened to me just now right in the fraction of a section between typing text and hitting win-s which on my desktop opens konqueror, Kongueror opened just fine, but the colour of the title bar indicated that it did not have focus.
It seems to be entirely random.
Its rate of occurrence seems to be, on average, once every few hours (of activity).
I leave the system up and running overnight, and so far it's been fine in the morning. So it doesn't seem to happen when there's no activity.

I am installing the current packages from the repository, and will let you know if I see the problem again once those packages are installed.

@N7DR thanks for the extra feedback and for the extra testing. This will be useful, especially to test a potential fix once the updated packages will be uploaded (see PR #437).

We will let you know when the packages with the potential fix are ready for testing.

@jstolarek @N7DR
if you didn't experience any issue since yesterday, could you update to the latest PSB packages, restart twin and test again? We have incorporated what we believe is a fix for the original problem and your support in testing would be super useful.
Make sure the package version has a .2 towards the end, that is the one with the fix. Currenty you are probably running .1.

This message came through email rather than GUI. I have added it here as I guess this was the original intention of the author (@N7DR).

@MicheleC mentioned you:

@jstolarek ( https://mirror.git.trinitydesktop.org/gitea/jstolarek ) @N7DR ( https://mirror.git.trinitydesktop.org/gitea/N7DR )
if you didn't experience any issue since yesterday, could you update to the latest PSB packages, restart twin and test again? We have incorporate what we believe is a fix for the original problem and you support in testing would be super useful.
Make sure the package names has a.2 towards the end, that is the one with the fix. Currenty you are probably running.1.

No issue since downloading yesterday (which is a great relief; the bug was /extremely/ annoying); I will download and try the .2 later today, and let you know how it goes.

I see that the version that was downloaded yesterday was:
4:14.1.2~pre28-0debian12.0.1+3

I imagine that the .1 at the end of the string "12.0.1" is what will change to 2 when I download later today.

I imagine that the .1 at the end of the string "12.0.1" is what will change to 2 when I download later today.

Yes, correct.

.1 is tdebase with a reverted commit, the one we suspect was causing the issue.
.2 is tdebase with a potential fix for the problem, which is what we want to test. If it works fine for a few days, then we will merge it. If not, back to work to understand the problem further.

The fact that .1 didn't give any issues seems to confirm that the problem is caused by the commit in PR #411, which was our guessing.

I also upgraded but I won't be using my PC over the weekend so I can only provide further feedback on Monday.

Upgraded here this morning; so far no problems.

I have not run into the bug for the past two days.

Ditto.

Thanks for testing @jstolarek and @N7DR. The fix has been merged into the code. If you experience the same issue again in coming days, please reopen the issue.