Mouse button clicks by itself on certain Linux distro

Running this simple application on Debian 11 or Ubuntu 21 happens that the mouse clicks by itself when it is moved on a menu item or a button. Instead the program run fine on Centos 7.

To Reproduce Using Debian 11 fresh installation I tried on VirtualBox, VMware. On Ubuntu 21.10 using a phisical machine. In all cases the issue happens. Both Self-contained and Framework-dependent package are affected.

Below the X configuration of the Debian machine running on VirtualBox:

X.Org X Server 1.20.11
X Protocol Version 11, Revision 0
Build Operating System: linux Debian
Current Operating System: Linux debian11 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-11-amd64 root=UUID=f1bba9df-a607-496e-931f-1f89956d6b31 ro quiet
Build Date: 16 December 2021  05:08:23PM
xorg-server 2:1.20.11-1+deb11u1 (https://www.debian.org/support) 
Current version of pixman: 0.40.0

The simple program The program has been wrote using VS2022, framework .NET 6.0 (6.0.2), Terminal.Gui 1.4.0 The issue occurs also on more complex programs.

using Terminal.Gui;
using NStack;

Application.Init();
var top = Application.Top;

// Creates the top-level window to show
var win = new Window("MyApp")
{
	X = 0,
	Y = 1, // Leave one row for the toplevel menu

	// By using Dim.Fill(), it will automatically resize without manual intervention
	Width = Dim.Fill(),
	Height = Dim.Fill()
};

top.Add(win);

// Creates a menubar, the item "New" has a help menu.
var menu = new MenuBar(new MenuBarItem[] {
			new MenuBarItem ("_File", new MenuItem [] {
				new MenuItem ("_New", "Creates new file", null),
				new MenuItem ("_Close", "",null),
				new MenuItem ("_Quit", "", () => { if (Quit ()) top.Running = false; })
			}),
			new MenuBarItem ("_Edit", new MenuItem [] {
				new MenuItem ("_Copy", "", null),
				new MenuItem ("C_ut", "", null),
				new MenuItem ("_Paste", "", null)
			})
		});
top.Add(menu);

static bool Quit()
{
	var n = MessageBox.Query(50, 7, "Quit Demo", "Are you sure you want to quit this demo?", "Yes", "No");
	return n == 0;
}

//Application.UseSystemConsole = true;  // without influence ???
Application.Run();
Application.Shutdown();

Screenshots As you can see, the mouse button clicks by itself, I never clicked the mouse button.

Thanks Many thanks to the creators and maintainers of this useful piece of software. I’m at your disposal for any information.

[BDisp]

Do the affected distros have this issue with other ncurses programs?

I’ve read those that use native library with c or python do not have this issue. But the Terminal.Gui uses the libc, libncurses.dylib, libncursesw.so.6" or libncursesw.so.5, by loading the methods through delegates. First, if Mono is present CursesDriver will obtain the address of the symbols from a dlopen object in the Mono.dlsym, otherwise will obtain in the return CoreCLR.dlsym if is NetCore. If none exist it will obtain in the Linux.dlsym. But if it’s only a Terminal.Gui issue, why with the Ubuntu 20.04 distro the mouse move works and in the Debian 90 distro don’t. The only reason I see is the Debian works differently. I already read that the Debian team doesn’t compile the ncurses with all the necessary arguments. The gpm is needed to compile with mouse library.

Do you mean that ncurses is getting ‘bad’ code events from the OS? If so is it possible that there is just a change in the structure of those events (e.g. similar to #2008)? Maybe we are expecting some bit code and instead getting different ones?

On Debian 9.0 distro mouse move isn’t caught at all and the others events doesn’t match the one the Ubuntu receives. With the latest of installable versions of Ubuntu and Debian the ncurses always return always the same code event. So I already removed them. No it’s having nothing with the #2008, which we receive correct code an we remap to the correct output values. The issue is we are receiving wrong code from the ncurses itself and there are no way do decode them because they are inconsistent.

Could you explain more about this? It sounds like you have an idea about what is going on? What would a ‘database change’ look like? and why does it not affect other apps e.g. htop (unless it does!)

I mean about the Termcap and Termunfo databases where can be configured soe keys, mouse and others information on how the terminal will respond to the commands. I don’t know on what language htop is developed, but it’s with native C the ncurses works well. I think they uses c library that has a correct of a compiled ncurses. But I’m not an expert on Linux. I only starting learning and understanding some ncurses methods with the Terminal.Gui. Perhaps some of the ncurses methods or structs may being badly created and binding in the Terminal.Gui, but in that case it also work badly with all the Linux versions.

I think if we can establish clear definitions of the input code formats that we are seeing in different OS versions it wouldn’t be out of the question to build in some ‘mapping’ classes that translate to the common representation for that version?

I think we can’t establish clear definitions of the input code formats that we are seeing in different OS versions without mapping them to a common representation that the Terminal.Gui cans process them.

[BDisp]

Thankful to this response from @DHowett in https://github.com/microsoft/terminal/issues/10321#issuecomment-1295928230, I already know how to fix this issue.