Mouse-based selection stops working after using the mouse in an app.

[madsbangh]

(Reproduced on Microsoft Windows Terminal)

When I run cabal -fdemos run brick-viewport-scrollbars-demo any subsequent mouse-based selection of text in the terminal window stops working.

Below you can see a gif of the reproduction.

I am unsure if this is an issue in Vty or Brick, but I am not sure I am experienced enough to verify it myself.
Thanks, and I hope this helps :)

[jtdaugherty]

@chhackett - could it be that mouse mode state is not being restored / deactivated?

[chhackett]

I did some testing using vty-mode-demo.

I reproduced the problem in WT. Noticed there is no problem in a bare cmd window.

In both cases, the mouse mode enabled/disabled sequences are emitted as expected when the app starts/ends.

But there is a slight difference in the escape sequences sent to the output.
Plain cmd shell emits an extra civis sequence (\ESC[?25l) on startup.

Not sure what that has to do with mucking up the mouse select. And I'm not sure why that happens.

But apparently, in WT, mouse mode is not disabled when the vty app shuts down. If I run vty-mode-demo a second time, mouse mode is enabled without me toggling it on. Somehow WT is ignoring the mouse disable sequences that are emitted on shutdown.

I'll look at it more later this week.

[jtdaugherty]

Thanks, @chhackett!

[ShrykeWindgrace]

Another instance of the same problem - hledger-ui built against vty-6.1, brick-2.1.1, vty-crossplatform-0.4, and vty-windows-0.2 exhibits the same symptoms.

I spend all day trying to understand why we lose mouse events upon the app exit, to no avail for now.
Worst case scenario, we setMode t Mouse True (currently False) on exit, but I'd like to understand what's going on.

Ref: simonmichael/hledger#2112

[chhackett]

Yeah, I've spent at least 5 or 6 hours on it so far, and I'm no closer to understanding it.

But like you said, we can put in a workaround. I might just do that as a temporary solution and just open another issue on vty-windows to fix it the right way.

[jtdaugherty]

What’s confusing to me about this Is that the image shows that mouse mode is getting left enabled on exit. The mouse selection behavior shows that mouse mode is disabled before the program runs, and left enabled when it exits, thus interfering with the normal selection behavior. I mention this because my interpretation doesn’t line up with some of the discussion above - and it leaves me really confused about why explicitly enabling mouse mode on exit would have the desired effect, since I would expect the opposite to be true.

[ShrykeWindgrace]

@jtdaugherty I think that's a issue of definitions. One might say that "mouse is enabled" in a (regular) terminal if mouse scrolling and mouse selection works. Or one might say that "mouse is enabled" if terminal passes mouse events to the currently running program.

@chhackett I have an idea - IIRC, you implemented a hack for FocusEvents regarding "Focus events are still sent even if there were told to disappear" in chhackett/vty-windows#1 I think that we are facing the same problem here, but for MouseEvents.

pwsh sessions can be "cured" with a Write-Host "`ec" (that's a "reset terminal" VT sequence aka \ESCc), but that loses everything.

[jtdaugherty]

@ShrykeWindgrace in general I agree, but there is already a definition in use here: the Vty API uses setMode .. Mouse True to mean “enable mouse mode” and False to mean “disable mouse mode.” That is the operating definition we need to use to be consistent in talking about this.

In other terminal emulators, the behavior is the same: when mouse mode is disabled, that means it is disabled from the perspective of the application, meaning the emulator will do what it wants with mouse events (e.g. perform text selection). But when it is enabled, mouse events are passed to the running terminal application and the emulator does not handle the events. That behavior is consistent with how the Vty API works.

[chhackett]

So I tried @ShrykeWindgrace solution to emit the 'reset terminal' sequence on shutdown.
It works. After application exits, mouse selection behaves as expected in the terminal.

But like you said, it resets everything, including the screen. So it replaces one bug with another.

What is so annoying about this is that mouse behaves correctly in the terminal emulator if I manually toggle mouse mode to disabled (ie. setMode .. Mouse False), and then exit the application. In both cases (manually change mouse mode to False or the application changing the mouse mode as part of the 'releaseTerminal' IO action) the mouse mode disable sequence is emitted to the output.

I'm guessing the difference in behavior might have something to do with the order or timing of sequences being sent to the output on shutdown. But I could be wrong. Anyway, I have a few more ideas to test...

[chhackett]

@ShrykeWindgrace @jtdaugherty

OK, I finally figured it out. It is an order of events issue. On shutdown, vty does:

                shutdownInput input
                releaseDisplay out
                releaseTerminal out

Unfortunately, calling shutdownInput first in the windows version calls the Windows API to reset the 'virtual terminal input' mode to False. So Windows was then ignoring the subsequent calls to reset mouse mode (which are obviously VT sequences).
I am a little baffled as to why it doesn't also ignore the command to exit the alternate screen buffer or show the cursor. Maybe those just happen automatically when the app exits, so we don't even need to bother sending those sequences. (will look into it later maybe)

So I just re-ordered the shutdown sequence to:

                releaseDisplay out
                releaseTerminal out
                shutdownInput input

and mouse mode successfully resets now. Sorry for the long wait...

[jtdaugherty]

That's great news, congrats on tracking this down!

[chhackett]

Version 0.2.0.1 of vty-windows is released.

[jtdaugherty]

@madsbangh can you upgrade and confirm? Then we'll close this.

[ShrykeWindgrace]

@chhackett that's quite a find! Thanks a lot!

[madsbangh]

@jtdaugherty This is awesome news! Well done @chhackett and all! I will verify it on my end later today <3

[madsbangh]

@jtdaugherty ✅
I can confirm on my end that this works as intended now.

I ran cabal update and then cabal -fdemos run brick-viewport-scrollbars-demo, causing the new vty-windows 0.2.0.1 to be downloaded.

After quitting the demo app, I now regain the ability to select with my mouse etc in the Windows terminal as expected :)

[jtdaugherty]

Great, thanks!