Scid / Bugs / #233 SCID focus bug on Linux

Distro	GPU	NVIDIA driver version	The bug happens?
Ubuntu 22.04 LTS	NVIDIA GTX 1060	`550.90.07`	No
Fedora 40 Workstation	NVIDIA GTX 1060	`555.58.02`	Yes
Fedora 40 Workstation	NVIDIA GTX 1050 Laptop	`550.107.02`	Yes
Debian 12	NVIDIA RTX 4060 Laptop	`545.29.06`	No
Debian 12	NVIDIA RTX 4060 Laptop	`535.xx.xx`	Yes
Kali 2024.1	NVIDIA GTX 1060	`525.147.05`	Yes
Kali 2024.1	NVIDIA GTX 1060	`535.161.08`	Yes

Ruggiero A - 2024-08-04

I forgot to add that when the bug happens, the application will lose focus (FocusOut event on .main) basically as soon as a piece is pressed with the mouse. Also clicking on tabs applies. The events may not trigger at the very beginning of the launch of the application, but eventually they will start arising and they will happen basically after every click in the app.

When .main is unfocused, no input from the keyboard will work untill focus is again forced, such as switching applications.

The issue makes the application very unusable when the application is used for PGN editing, which requires a ton of keyboard usage.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ruggiero A - 2024-08-05

I may have made some advancements in reproducibility.

I used this virtual machine image (Ubuntu 22.04 LTS) on my Fedora 40, with VirtualBox 7.0.20, and I manually installed VirtualBox Tools beforehand and restarted (I guess that the image straight for VBox can also work for the purpose, but to clarify what I did exactly use), and the problem still appears. I attach a screenshot where tcl/main.tcl was modified adding the lines in the post, just for log purposes, but the problem appears even in the fresh download of the application.

As you can see in the screenshot, FocusOut event on .main as last line appears, which means that the input from sources like keyboard is now detached and is not inserted anymore. Such line gets logged basically when I press on any piece but also other graphical inputs such as tabs.

The fact that the problem appears to VMs as well may suggest it can be a more general problem than previously thought, since the application should work properly even in a VM setting.

I also tested it on a Fedora 40 VM and the results were similar although the second run the program made my VM freeze completely so that's why I suggest a Ubuntu 22.04 LTS VM instead.

Other info of how I configured the VM:

System
Base Memory: 2048 MB
Processors:
Acceleration: Nested Paging, KVM Paravirtualization

Display
Virtual Memory: 128 MB
Graphics Controller: VMSVGA
Acceleration: 3D

Host computer, the one with GTX 1060 of the main post.

EDIT (IMPORTANT): Curiously on this VM, the problem appears to happen on Wayland (default for the image), but not when X11 is enabled. While on my desktops, X11 seems also affected.

EDIT 2: I add an attachment with Fedora 40 on X11 and the problem still appears.

Last edit: Ruggiero A 2024-08-05

Screenshot from 2024-08-05 13-27-47.png

Screenshot from 2024-08-05 14-01-32.png

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Fulvio - 2024-08-07

In theory, the video driver should not affect the keyboard/mouse focus, so maybe it is related to multiple displays?

Adding this lines at the end of end.tcl should provide improved diagnostics:

bind all <FocusIn> {+puts "([clock milliseconds]) <FocusIn> %W"} bind all <FocusOut> {+puts "([clock milliseconds]) <FocusOut> from %W to [focus -displayof %W]"}
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ruggiero A - 2024-08-09

In theory, the video driver should not affect the keyboard/mouse focus, so maybe it is related to multiple displays?

So far the bug has happened both with only one display, on the laptop with Debian 12, and on my other PC with OSes different than Ubuntu. It does not seem related to multiple displays.

Also I don't think it's just a focus problem. There are probably at least some errors happening in the background, since the application also is sensibly slower when the bug happens (still usable in regards of velocity, but it seems not working "right" as in other circumstances).

At this point I think that Nvidia driver is only a variable but not the only one; there is likely something else also going on. I suppose it's a combination of OS + Version of Nvidia drivers + Window Manager (X11/Xwayland). I find hard to make it either work or malfunction deterministically because every distro has some rigid specific versions of packages which you can't easily alter. What I've found however is that outside Ubuntu is at least somewhat common to reach these bugs as it was reached for now up to 3 different PCs and also a VM. So I don't think it's rare either.

Adding those lines at the end of end.tcl file, this is what I get

$ ./scid (1723199637034) <FocusIn> .tipsWin (1723199638358) <FocusIn> . (1723199638358) <FocusIn> .fdockmain (1723199638359) <FocusOut> from .fdockmain to .main.board (1723199638359) <FocusOut> from . to .main.board (1723199638359) <FocusIn> .main (1723199638360) <FocusIn> .main.board (1723199640109) <FocusOut> from .main.board to (1723199640109) <FocusOut> from .main to

It still takes just very few moves (even just a couple) to get the bug going. As you can see, <FocusOut> from .main is still the last event that gets logged (even If I keep inserting more moves). It behaves as if I focused on something else in the OS. And it unfocuses right in the moment I click on a piece to move it.

I tried to switch with monitors on mirror mode instead of join mode but it's still the same problem; also again, I didn't have a multiple monitor when I used the application on Debian.

Last edit: Ruggiero A 2024-08-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Fulvio - 2024-08-11
  
  It behaves as if I focused on something else in the OS.
  
  I took it for granted, but it's better to clarify it explicitly. The OS shows that SCID is still the active window, right? Because otherwise, there really is some other application stealing the focus.
  
  And it unfocuses right in the moment I click on a piece to move it.
  
  Maybe you can also add ButtonRelease to the log:
  bind all <ButtonRelease> {+puts "([clock milliseconds]) <ButtonRelease> %W (focus: [focus -displayof %W])"}
  
  Are you compiling SCID with cmake or configure && make? Did use the default params?
  What's the version of the system Tcl/Tk library ( apt-cache policy tcl-dev tk ) ?
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ruggiero A - 2024-08-11

There is a start like this

[...] (1723412291061) <FocusIn> .fdockmain (1723412291062) <FocusOut> from .fdockmain to .main.board (1723412291062) <FocusOut> from . to .main.board (1723412291062) <FocusIn> .main (1723412291064) <FocusIn> .main.board)

Then I start making some moves

(1723412291430) <ButtonRelease> .main.board.bd (focus: .main) (1723412291430) <FocusOut> from .main.board to .main (1723412292454) <FocusOut> from .main to (1723412293582) <FocusIn> . (1723412293582) <FocusIn> .fdockmain (1723412293583) <FocusOut> from .fdockmain to .main (1723412293583) <FocusOut> from . to .main (1723412293583) <FocusIn> .main (1723412295821) <FocusOut> from .main to (1723412296415) <ButtonRelease> .main.board.bd (focus: )

After the last FocusOut event, it only logs the releases when I play other moves on the board:

(1723412304827) <ButtonRelease> .main.board.bd (focus: ) (1723412307256) <ButtonRelease> .main.board.bd (focus: ) (1723412308866) <ButtonRelease> .main.board.bd (focus: ) (1723412309787) <ButtonRelease> .main.board.bd (focus: ) (1723412310800) <ButtonRelease> .main.board.bd (focus: ) (1723412311925) <ButtonRelease> .main.board.bd (focus: )

To me it's something different than "some other application steals the focus", because actually focusing on other windows is something that very temporarily "fixes" this bug, e.g., after I focus out and come back to SCID and make a move, this is the following log:

(1723412618681) <FocusIn> . (1723412618681) <FocusIn> .fdockmain (1723412618681) <FocusOut> from .fdockmain to .main (1723412618681) <FocusOut> from . to .main (1723412618682) <FocusIn> .main (1723412618976) <ButtonRelease> .main.board.bd (focus: .main) (1723412621411) <FocusOut> from .main to (1723412622251) <FocusIn> . (1723412622252) <FocusIn> .fdockmain (1723412622253) <FocusOut> from .fdockmain to .main (1723412622253) <FocusOut> from . to .main (1723412622253) <FocusIn> .main (1723412623239) <FocusOut> from .main to

So it can temporarily re-gain focus and indeed also keys from the keyboard work. Unfortunately, as the logs show, it still proceeds to lose focus again.

Getting back focus is as easy as moving the cursor outside the SCID's window and then inside again; this can seen both by the logs and by trying to use the application (e.g., pressing arrow keys)

I took it for granted, but it's better to clarify it explicitly. The OS shows that SCID is still the active window, right? Because otherwise, there really is some other application stealing the focus.

OS-wise, SCID seems indeed the focused application. It does not appear to lose focus as application. It appears that only the GUI controls inside lose focus, e.g. .main. The window seems to be focused all the time and like I said, it's actually focusing out of the window and then back in which very temporarily "fixes" it.

What's the version of the system Tcl/Tk library

My TCL version is 8.6.13 both in the OS both what SCID uses on its own (since it's embedded in the bundle). I attempted to change it (to 8.6.14) with some shenanigans at compilation, and I think I succeeded from what I could as well log from the application, but it brought no success (= no change). Also the problems as I said in the other thread appears with every SCID (downloaded, flatpak, compiled).

Are you compiling SCID with cmake or configure && make? Did use the default params?

This time I used configure && make, last time instead cmake; it made no difference. Anyway compiling SCID is not necessary to edit .tcl files since they are in the bundle of the program even in its binary version (as they do not get compiled I think), so I can do the tcl "experiments" even with the distributed version.

About the focus stealing hypothesis, I asked ChatGPT to produce a shell script to monitor the active window. Since the one it provided only works in X11 I used X11 as window manager.

This is the script

#!/bin/bash # Initialize a variable to store the last active window ID active_window_id="" # Infinite loop to continuously monitor the focused window while true; do # Get the ID of the currently active window new_window_id=$(xdotool getactivewindow) # Check if the new window ID is different from the last one if [ "$new_window_id" != "$active_window_id" ]; then # Update the active window ID active_window_id=$new_window_id # Get the process ID (PID) of the window pid=$(xprop -id $active_window_id | grep "_NET_WM_PID" | cut -d " " -f 3) # Check if PID is not empty and valid if [[ -n "$pid" && "$pid" =~ ^[0-9]+$ ]]; then # Get the command name of the PID process=$(ps -p $pid -o comm=) # Print the name of the focused application echo "Focused application: $process" else echo "Could not determine the PID for the active window." fi fi # Wait for a short period before checking again sleep 0.5 done

And it works for normal applications

Focused application: gnome-terminal- Focused application: firefox Focused application: gnome-terminal-

But for SCID it does not as it appears that the _NET_WM_PID property is not set.

Could not determine the PID for the active window.

E.g., when trying to get its properties in X11 (see attached screenshot)

# I focus on SCID in the meantime that the sleep commands waits $ sleep 1 && xdotool getactivewindow 54526102

xprop -id 54526102 | grep "_NET_WM_PID" yields no output with error. So the window does not have a _NET_WM_PID property.

However, what I also see from such script running, is that no other application appears to be stealing focus from SCID (there are no more lines printed after Could not determine the PID for the active window.); so it's not just the window appearance (which looks normal), but this makes a redundant confirmation about it. I think the focus problem is "inside" SCID; the process is focused but the GUI inside is not anymore

Of course the script could be modified to use other properties instead of _NET_WM_PID but maybe the former can be more precise since different windows of the same applications have different _NET_WM_PID properties although sharing the same application name, but for the purpose of this test I don't think it makes a difference past this.

I do not know more reasons behind the bug as I have no prior experience with Tcl/Tk besides these basic attempts to log stuff.

I'd say, if you have enough time (and will) to test this, could you try to use the same VM image I used as well? I provided it in my previous answer (link to image: https://www.osboxes.org/ubuntu/#ubuntu-22-04-jammy-vmware), I downloaded the disk image for VMWare even if I used then in VirtualBox (it could make no difference to use immediately the one for VirtualBox, but to stay consistent with my trial); then I installed the VirtualBox tools manually and rebooted. After rebooting and downloading SCID, SCID appears to have the same bug I describe on such VM, so you may investigate it from there if the same happens to you as well. What curiously happened to me as well on such VM, and only on that, is that the bug there happens only on Wayland and not on X11. Whereas on Fedora and other distros the bug happens on both. So the window manager could be a variable although it is not definitive. But I suppose it can be enough for you to troubleshoot the problem and eventually solve it.

Last edit: Ruggiero A 2024-08-11

Screenshot from 2024-08-11 23-59-02.png
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Fulvio - 2024-08-12

There's a parameter in xdotool that returns the window title:

#!/bin/bash last_window="" while true; do current_window=$(xdotool getwindowfocus getwindowname) if [ "$current_window" != "$last_window" ]; then echo "$(date '+%Y-%m-%d %H:%M:%S.%3N') - $current_window" last_window="$current_window" fi sleep 0.1 done

My TCL version is 8.6.13 both in the OS both what SCID uses on its own (since it's embedded in the bundle).

The Linux binaries are automatically compiled on an Ubuntu 20.04 VM in Microsoft Azure's cloud. Distributing binaries across different Linux versions can be challenging due to potential incompatibilities. This could also explain why changing the NVIDIA driver resolves the issue; it's not necessarily the driver itself but the updated system libraries that accompany it.

> > (1723412295821) <FocusOut> from .main to > (1723412296415) <ButtonRelease> .main.board.bd (focus: ) >

The focus was lost 0.6 seconds before releasing the mouse button.
Please add a log for the 'a' key:
bind all <a> {+puts "([clock milliseconds]) Keyboard event in %W - Focus: [focus] - Display focus: [focus -displayof %W]"}
and press that key when you encounter the issue. Because if the OS does not send the keyboard input to SCID, there is nothing that we can do.

Last edit: Fulvio 2024-08-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ruggiero A - 2024-08-12

From the shell script, no application seems to be stealing focus

./focus_logger2.sh 2024-08-12 14:55:15.015 - ./focus_logger2.sh 2024-08-12 14:55:20.013 - gnome-shell 2024-08-12 14:55:21.056 - Scid - <clipbase> (game 0 / 0) 2024-08-12 14:55:35.397 - ./focus_logger2.sh

(I came back manually to the terminal about the last log line

This could also explain why changing the NVIDIA driver resolves the issue; it's not necessarily the driver itself but the updated system libraries that accompany it.

This is what I kind of think as well, since I attempted to install the same NVIDIA driver version I have on Ubuntu on my Fedora as well, and it was not enough to make it work; but so far I could not deduce more specific variables about this.

The focus was lost 0.6 seconds before releasing the mouse button.

This is not weird. From what I already saw, the focus is lost as soon as I click (mousedown event) on a piece, not after I release it (it is already lost by then); the application allows me to play other moves with my mouse even though the focus is technically "lost", but the keyboard does not send any more inputs at that point.

Please add a log for the 'a' key:
bind all <a> {+puts "([clock milliseconds]) Keyboard event in %W - Focus: [focus] - Display focus: [focus -displayof %W]"}
and press that key when you encounter the issue.

Just did this; the event is correctly logged when the focus is working (e.g., after having started the application, or after switching windows), but unfortunately it does not get logged when the bug is occurring (after FocusOut event)

Because if the OS does not send the keyboard input to SCID, there is nothing that we can do.

About this, to experiment, I asked ChatGPT to prompt a little hello world application in Tcl/Tk, it yielded this code

#!/usr/bin/env wish # Create the main window set root .root toplevel $root wm title $root "Hello World - Tcl/Tk" # Create a frame to organize widgets frame $root.frame pack $root.frame -expand true -fill both -padx 10 -pady 10 # Add a label label $root.frame.label -text "Hello, World!" pack $root.frame.label -side top -pady 5 # Add a text entry field entry $root.frame.entry -width 40 pack $root.frame.entry -side top -pady 5 # Add some buttons button $root.frame.button1 -text "Button 1" -command {puts "Button 1 pressed"} button $root.frame.button2 -text "Button 2" -command {puts "Button 2 pressed"} pack $root.frame.button1 -side left -padx 5 -pady 5 pack $root.frame.button2 -side left -padx 5 -pady 5 # Focus tracking and event logging bind all <FocusIn> {+puts "([clock milliseconds]) <FocusIn> %W"} bind all <FocusOut> {+puts "([clock milliseconds]) <FocusOut> from %W to [focus -displayof %W]"} bind all <ButtonRelease> {+puts "([clock milliseconds]) <ButtonRelease> %W (focus: [focus -displayof %W])"} bind all <a> {+puts "([clock milliseconds]) Keyboard event in %W - Focus: [focus] - Display focus: [focus -displayof %W]"}

(attached screenshot)

From its log, nothing suspicious happens, e.g. no "FocusOut" event unless I truly focus out of the application; clicking buttons, background, text field, etc., does not appear to raise any anomaly; I understand it's a very simple example but on the other hand to me the bug on SCID happens very soon after I start using the application

Also, I don't know if somehow it can be relevant, but the logs on this test application seem to be a little more detailed:

(1723468567879) <FocusIn> .root (1723468567880) <FocusIn> .root.frame (1723468567880) <FocusIn> .root.frame.entry Button 1 pressed (1723468568702) <ButtonRelease> .root.frame.button1 (focus: .root.frame.entry) Button 2 pressed (1723468568987) <ButtonRelease> .root.frame.button2 (focus: .root.frame.entry) (1723468571281) <ButtonRelease> .root.frame.entry (focus: .root.frame.entry) (1723468571749) Keyboard event in .root.frame.entry - Focus: .root.frame.entry - Display focus: .root.frame.entry (1723468572092) Keyboard event in .root.frame.entry - Focus: .root.frame.entry - Display focus: .root.frame.entry (1723468572276) Keyboard event in .root.frame.entry - Focus: .root.frame.entry - Display focus: .root.frame.entry Button 1 pressed (1723468573321) <ButtonRelease> .root.frame.button1 (focus: .root.frame.entry) Button 2 pressed (1723468573674) <ButtonRelease> .root.frame.button2 (focus: .root.frame.entry)

(Notice that the focus: target inside the parenthesis is not empty)

Since this simple example works on the same machine/distro where SCID encounters the bug, this may suggest that there is some specific issue happening with SCID. I don't know which is it and I could attempt to investigate better, but from this little trial, to me it seems that the problem could be fixed within SCID, somehow.

Screenshot from 2024-08-12 15-12-22.png
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Fulvio - 2024-09-05

status: open --> closed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Fulvio - 2024-09-05

I cannot reproduce it (KDE Debian 12), but in any case, there is nothing I can do.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ruggiero A - 2024-09-25

I have come yet one more time as I finally found out more about this and I must object a few things,

I cannot reproduce it (KDE Debian 12),

I understand. That's why I provided a link in one of my previous answers to a virtual image so that the problem should be reproducible on every computer. I am not claiming it is necessary to use such virtual image to investigate the problem, but of course when the problem just does not arise on your machine, it is not easy to understand what's going on if nothing suspicious is going on; that's why the virtual machine.

Also before I continue, let me remind you that I have gone across this problem on 3 different machines, one that is from a friend of mine, the other two mine, and it has happened both on X11 and Wayland (on Fedora/GNOME). So this problem can possibly occur on many PCs with Linux and since this software is appealing to Linux users for obvious reasons, I don't think the issue should be underestimated and closed like that.

That said, I have not come here to complain, and I want to challenge your last statement

but in any case, there is nothing I can do.

The newest model from ChatGPT, o1-preview, helped me ton more than the previous ones into investigating this issue (and it suggested on its own that focus bugs may have temporary workarounds such as switching windows with Alt-Tab, which is something I reported as well months ago); I don't think that's surprising. It's a more and more powerful tool, and as said many times I do not have specific competences in Tcl/Tk so it's very hard the least for me to investigate this problem by myself in this enough-big codebase for which I should spend days to weeks just into understanding what's going on.

The model explained me many things that may affect/compromise focus in Tcl/Tk, and I have indeed seen that SCID does do a lot of things related to focus. Recall from my previous answer that my Hello-World application did not present the bug that SCID presents on my machine, suggesting, as I said, that the bug likely lies in SCID, not in the libraries or the OS.

Of course, I cannot understand how completely SCID handles the focus of the several widgets, but what I've found out so far is that there are a lot of grab calls, a lot of focus calls, and some interesting snippet such as

# [File `main.tcl`, around line 570, ndr] bind .variations <FocusOut> { focus .variations raise .variations } # Needed or the main window loses the focus bind .variations <Destroy> { focus -force .main } catch { focus .variations } catch { grab $w }

Which makes me conclude that there has been some previous work already about focus issues on SCID, and I am not just imagining my problem out of nowhere nor it does happen only on my machine and nothing else.

Solution (or workaround?)

I do not know if this can be called as a solution yet; I have not yet deeply tested the whole application after this modification, but this seemingly fixes the issue happening on the board which is one of the most frustrating (that is, after some moves are drawn on the chessboard, the application persistently loses focus on every click on the chessboard and the workarounds are either switching constantly in and out from the window with the mouse, or changing windows; on some OSes, it gets even worse and the whole application becomes unusable)

After several tries, commenting in and out grab, focus statements around the application, with no success, after some more diagnostic with the focus events, ChatGPT helped me coming up with this block of code (especially the -force part which I missed, which is essential to make the snippet work)

# inserted at the end of end.tcl file bind .main.board.bd <ButtonPress> { puts "([clock milliseconds]) <ButtonPress> %W (focus: [focus -displayof %W])" focus -force .main }

Again, I do not know if this block solves actually all the possible problems which I ran upon, which are not very few. I have to test SCID more deeply for that, and on different configurations as well (just as I did so far), because it previously happened to me that even the textfield could bug after using the application so it could be not just the chessboard, but this snippet seems to work perfectly for what it regards the chessboard. Which challenges your statement that there is nothing you can do from your side, and that the bug must lie only in the OS/Tcl-Tk library version/Window Manager/other libraries. Because this snippet fixes a huge issue from "your side".

I hope that this issue finally gets heard of and addressed, and I personally think it should be opened again until the issue is not properly fixed (again, I provided an image where the problem should be reproducible on every machine)

EDIT: Just tested a bit, and indeed, it doesn't solve all the issues. E.g., when I open a database and attempt to search a game, the identical focus problem arises in the TextField; a similar workaround could be made for this part too, but again, my main point in this reply is that it indeed seems possible to address the problem within SCID codebase.

Last edit: Ruggiero A 2024-09-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ruggiero A - 2024-09-25

Seemingly, the related problem to the text fields can be individually "fixed" with the same workaround, e.g.,

bind .glistWin1.games.find.text <ButtonPress> { puts "([clock milliseconds]) <ButtonPress> %W (focus: [focus -displayof %W])" focus -force .glistWin1.games.find.text } bind .commentWin.cf.txtframe.text <ButtonPress> { puts "([clock milliseconds]) <ButtonPress> %W (focus: [focus -displayof %W])" focus -force .commentWin.cf.txtframe.text }

again put at the end of the end.tcl file.

I cannot say if the focus is mismanaged in other parts of the code (which would allow a central fix) which makes these individual, specific, workarounds necessary, but it is yet more proof that the issue I described from the beginning can be fixed within SCID.

I do not know in advance how many widgets in the application are affected by this bug on configurations where the bug arises.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

SCID focus bug on Linux | update + details

Group

Searches

Help

#233 SCID focus bug on Linux | update + details

Discussion