Mouse button clicks by itself on certain Linux distro

[iw1qlh]

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]

Thanks for reporting this. Can you test with the current main branch, please. I already reported some issues in this my comment #1452 (comment).
On WSL is worse. They change the behavior often.

[iw1qlh]

Both my simple program and UICatalog, compiled using a clone of the current main branch have the same problem.
In addition, I confirm that the issue occurs on the mouse wheel also.
I tried on a fresh installed Debian 11 machine.

It seems the mouse repeats the last operation:

• when I enter in the window without using the mouse then nothing happens
• when I click the mouse button then it repeats the click when the mouse is moved
• when I turn the mouse wheel up then it repeats the turn up when the mouse is moved
• when I turn the mouse wheel down then it repeats the turn down when the mouse is moved

I attach an image captured from UICatalog - Scenario: Mouse. Also in this case I clicked the mouse once.

I hope this will help.

[iw1qlh]

Forcing the use of the System Console the issue does not occur.
I tried on Debian 11 using both Terminal.Gui 1.4.0 and the clone of the current main branch.

Application.UseSystemConsole = true;  // now it works well on Debian 11

It may be something related to ncurses library.
This is what CursesDriver.cs ProcessInput receive when the mouse button clicks by itself

code: 256; wch: 409
ButtonState: Button1Clicked; ID: 0; X: 17; Y: 5; Z: 0
code: 256; wch: 409
ButtonState: Button1Clicked; ID: 0; X: 34; Y: 5; Z: 0
code: 256; wch: 409
ButtonState: Button1Clicked; ID: 0; X: 23; Y: 5; Z: 0

[BDisp]

Yes, the issue is CursesDriver related. It trigger Button1Clicked on mouse moves. I think is due to the Termcap Library which has some different configurations.

[iw1qlh]

Waiting for a definitive solution I added these lines to Program.cs:

        bool useSystemConsole = false;

        foreach (string arg in Args)
        {
            if (arg == "-usc")
                useSystemConsole = true;
        }

        // https://github.com/migueldeicaza/gui.cs/issues/1617
        if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
        {
            try
            {
                string release = File.ReadAllText("/etc/os-release");
                if (release.Contains("debian"))
                    useSystemConsole = true;
                if (release.Contains("ubuntu"))
                    useSystemConsole = true;
            }
            catch { }
        }

        Application.UseSystemConsole = useSystemConsole;
        Application.Init();

[BDisp]

In this case you are using NetDriver and not CursesDriver. The solution is discover the magic sequence escape that will work correctly.

[BDisp]

It seems the mouse repeats the last operation:

I confirm that the mouse in Debian repeats always the last operations. @tznind since you normally uses Debian do you have this issue? I have downloaded here (https://www.debian.org/download) and installed on VirtualBox. I think the Debian doesn't have the correct terminfo information. With Ubuntu installed on VirtualBox I don't have this issue.
On WSL there are others mouse issues on both Ubuntu and Debian distros, like button release event is never triggered.

[tznind]

@BDisp I have Ubuntu 20.04.3 LTS on my laptop (not virtual) and it doesn't exhibit this behavior.

echo $TERM gives me xterm-256color. I use both Terminology and Terminator consoles neither of which have a problem with mouse repeats.

[BDisp]

Thanks @tznind for the information. Is a laptop only with Ubuntu or dual boot? With the virtual Ubuntu I don't have any problem too.

[tznind]

Thanks @tznind for the information. Is a laptop only with Ubuntu or dual boot? With the virtual Ubuntu I don't have any problem too.

Just Ubuntu only, its too old for Windows (but I have a soft spot for it so won't get a new one). My main dev machine is Windows.

I've had it running MX Linux before and also had no problems with mouse in Terminal.gui but that was a while ago.

[tig]

Closing as not-repo

[cpacejo]

I can reproduce this reliably on both Debian and Ubuntu, in both Gnome Terminal and xterm. Once I've clicked the mouse button once, it forever sends click events. It makes CursesDriver unusable for me. How can I help debug this?

[BDisp]

With the most recent Debian and Ubuntu versions indeed the mouse always repeat the last event used, if was a click will send forever clicks. Of course this only happens with the CursesDriver, using the -usc argument in the UICatalog or UseSystemConsole = true it work properly. I'm using the Debian 9.0 distro and the mouse move and wheel doesn't work. I'm also using the Ubuntu 20.04 distro where the mouse move and wheel works fine. As virtual machine I use the Linux Mint which work very well.
I understand we have to concern with different OS (Windows, Mac and Linux) and adapting the developing for them, but I'm upset about the worry of adapt the development for each Linux version. In my opinion the ncurses library should work in the same way with all the Linux versions. I already tried to check what going on but the ncurses always receives the same code event, so it isn't a mapping from ncurses to Terminal.Gui issue but it's the Linux version issue. I'm convict that is a xterm database changed in each version but for what reason? If a Linux user want to change that it can do it after the installation, but do not come within the installation.

[tznind]

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

I already tried to check what going on but the ncurses always receives the same code event

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?

I'm convict that is a xterm database changed in each version but for what reason?

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 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?

[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.

[tznind]

Thanks for such a deep analysis. Sounds like quite a challenge. But also that there might be a solution involving picking the correct library version or indicating to the developer/user that they are running against a dependency that is missing required compile options.

Should we reopen this issue or create a new one do you think?

I get that this is really a problem with distros and ncurses compilation versions but it would be nice if we could at least detect at runtime the issue and either shut off the mouse completely or otherwise indicate to programmer that a dependency is missing/misconfigured.

We could also just write some docs on how to get the right dependency installed on these newer distros if thats a thing that's reasonable to do.

[BDisp]

I agree. The docs is up to you :-). I'll continuous investigating this because I think the Debian and Ubuntu teams won't really broken the mouse features on terminals. I think you can reopen this issue.

[BDisp]

Thankful to this response from @DHowett in microsoft/terminal#10321 (comment), I already know how to fix this issue.