Gui.cs: Sometimes controls don't activate on mouse clicks

[tig]

This is really tricky to reproduce and I have not yet found a reliable way of reproducing it with the debugger.

1) Run demo.c in cmd.exe or ConEmu on Windows (any terminal that supports mouse).
2) Click on any control (e.g. a top-level MenuBarItem or one of the radio buttons.
3) Click on another control.
4) Then another
..
5) Eventually you'll notice one of your clicks does nothing; the target control does not get focus as expected. Clicking again will work.
6) You'll think you're crazy and you just either didn't hit the mouse button hard enough or missed the hit-target. But you didn't.
7) You'll try again and find you can't precisely reproduce it the same way.

P.S. I thought I had introduced this bug in my upcoming MenuBar PR and was actually quite happy to find it also exists in the current master and that it exists across all controls.

[BDisp]

Sometimes we think that we are clicking on the right place, for example in MenuBar we have to click on the letters and not outside. But it also happens to me a lot to make sure I clicked correctly and didn't get any action. I think that sometimes handlers become irresponsible and do not return certain actions.

[tig]

I'm 100% sure this is a bug and not me not clicking in the right place.

[BDisp]

I know you think you're right. This has happened to me many times. It turns out that many times without realizing it, we click so quickly that ReadConsoleInput captures double clicks and not just the click. There is a very small delay after there has been a double click in which case there is a new click before the end of the delay to capture the triple click. To be absolutely sure that it is a bug we have to click a little slower to be absolutely sure. But I confirm that it really happens but I still haven't been able to find out why it doesn't always happen in the same way and it's random. It is just to explain that the captured event may be a double click instead of a simple click.

[BDisp]

The issue in the mouse events response was due the line 133 of the Demo.cs have a
Application.MainLoop.AddTimeout (TimeSpan.FromMilliseconds (300), timer);
When a timeout comes up the main iteration return to run timers. So when a ButtonReleased is caught, the ButtonClicked isn't triggered until another event occurs.

[TylerLeonhardt]

I'm able to repro this as well. Mouse clicks work initially but eventually get to a point where they stop all-together 😢

[BDisp]

There is a new version that was merged today. I think it's more functional.

[BDisp]

But it is only working on Windows 10. Still working on Curses.

[BDisp]

I have been checking this mouse for bad behavior on CursesDriver and I think I have already figured out why. The problem now is how to solve it. Unlike WindowsDriver, the click cycle on the CursesDriver is different. The normal cycle of a simple click should be ButtonPressed-> ButtonReleased-> ButtonClicked. Now, in order to open and close the menus more quickly, it is logical to capture the ButtonPressed first to open or close the menu when pressing the button. This procedure works well with WindowsDriver. With CursesDriver the cycle of a single click is just ButtonClicked. To capture ButtonPressed we have to hold the button down longer and then release it. This does not make sense because as soon as the button is pressed, there should be a ButtonPressed event. I don't know if there is any update to the library that we can use. Any help would be welcome. The resources of CursesDriver are really reduced.

[tig]

FWIW, this bug is still a big issue for usability. I have found that I have to hold the mouse perfectly still to get a click to register.

[BDisp]

Do you meaning in the Unix? There is really some behaviours that I can still correct but the capture of the release button during a moving at same time, is never caught because of ncurses bug. But it's possible improved it thar now I already fixed the inactive unix driver.

[tig]

No, this is on Windows (99.9% of my usage is on Windows).

[BDisp]

I was too. Now, due to Terminal's multiplatform target, I felt compelled to learn Unix. Frankly, I haven't noticed many mouse failures in Windows. One click or another may fail, but compared to how it was before, I think it has improved. This behavior is due to the fact that, for example, if a particular view is waiting for a click, but if the mouse is in motion, the event sent is a button pressed and a report of mouse movement. Therefore, it is necessary to stabilize the movement of the mouse to trigger the desired event. If I ignore the movement of the mouse it will damage views that need both click and movement. Therefore, I am open to suggestions.

[tig]

I find Terminal.Gui usage almost unacceptable due to this bug at this point.

I absolutely think we need to figure out how to make the mouse work as reliably as it does in any other Windows app before we release 1.0.

[tig]

@BDisp I am wondering if you've looked at this recently?

I think this is the most critical bug that needs to be fixed before 0.90 can be released. The folks working on the Powershell out-consolegridview are holding up the release of that until the mouse works reliably.

You have more experience working on mouse handling so I have been assuming you would look into debugging this and then figuring out a fix. I'm happy to take it on if you don't want to or can't. Please let me know your preference.

Thanks.

[BDisp]

@tig I can try to solve it but I need to know in what system it happens and what kind of annoyances are they specifically?

[tig]

@tig I can try to solve it but I need to know in what system it happens and what kind of annoyances are they specifically?

Sorry, I thought it was so bad that it was obvious. I can 100% repro on Windows in cmd.exe (e.g. when debuggin in VS) and in ConEmu. It's likely my style of using the mouse causes me to see it regularly.

If the mouse is moving AT ALL when I click, the click is not captured.

I think this may be related to Window dragging. I have found that if I :

• position mouse outside of Window
• start moving mouse towards Window
• press the left mouse button while I continue to move

The Window will start moving. In otherwords, I do not have to click right on the Window frame to get it to start moving.

I think the mouse is getting captured by this, and thus the mouse event handling for 'clicked' is not seeing the event.

[tig]

Video:

[BDisp]

Really with windows dragging there are problems and this can cause strange behaviors. I have to check well because a Windowinside another Windowbehaves almost uncontrollably.

[TylerLeonhardt]

This fixed?

[BDisp]

This fixed?

Yes. But I think @tig still detects some strange behavior.

[TylerLeonhardt]

Even on non-Windows?

[BDisp]

For me it is working well in Windowsand Linux. I don't have a Mac.

[tig]

I think it is fixed. It was hard to reproduce before, and I've been trying since @bdisp made his latest changes that fixed some window dragging issues...I think they were the root cause.

Note that mouse is still broken in Windows Terminal. This is for all GUI apps, and is not specific to Terminal.Gui.

[TylerLeonhardt]

Awesome!