Mouse movement control sequences leak to terminal at app shutdown about textual HOT 10 OPEN

Didn't test with anything else; I'll try and remember to have a look the next time I'm at a machine.

from textual.

We found the following entries in the FAQ which you may find helpful:

• How do I center a widget in a screen?
• Why doesn't Textual look good on macOS?
• How can I set a translucent app background?

Feel free to close this issue if you found an answer in the FAQ. Otherwise, please give us a little time to review.

This is an automated reply, generated by FAQtory

from textual.

I took a shot at diagnosing this issue, and the issue disappears if we modify the shutdown sequence of the input thread to loop a few times more to drain the mouse movement sequences out from the input descriptor:

class LinuxDriver(Driver):
    ...
    def run_input_thread(self) -> None:
        ...
        countdown = 3

        try:
            with open("/tmp/textual_out", "a") as f:
                while not self.exit_event.is_set() or countdown > 0:
                    selector_events = selector.select(0.1)
                    for _selector_key, mask in selector_events:
                        if mask & EVENT_READ:
                            rdd = read(fileno, 1024)
                            unicode_data = decode(rdd, final=self.exit_event.is_set())
                            for event in feed(unicode_data):
                                self.process_event(event)
                    if self.exit_event.is_set():
                        print(
                            f"Exit event set, countdown: {countdown}, data: {rdd if mask & EVENT_READ else None}",
                            file=f,
                        )
                        termios.tcflush(fileno, termios.TCIFLUSH)
                        rdd = ""
                        countdown -= 1
        finally:
            selector.close()

I'm getting the following output in /tmp/textual_out if I move the mouse while quitting the application:

Exit event set, countdown: 3, data: b'\x1b[<35;101;46M'
Exit event set, countdown: 2, data: b'\x1b[<35;111;45M'
Exit event set, countdown: 1, data: 

so it looks like new mouse movement control sequences may appear on the linux driver's terminal file descriptor, even though the control sequence for disabling mouse support is already sent by disable_input, and the descriptor's input queue is flushed. I'm not sure how to proceed from here: this "draining" mechanism works to resolve this issue, but it looks very odd that we would have to do it.

from textual.

This issue does seem specific to certain terminal emulators, at least from running quick tests with:

• xterm
• urxvt
• alacritty
• terminator
• wezterm
• Xfce Terminal

from textual.

FWIW I couldn't reproduce it with kitty on macOS.

from textual.

@davep How about with macOS Terminal (just for confirmation as not one I'm able to check)?

from textual.

I've also now tested with Xfce Terminal which shows the same issue, which makes me wonder if perhaps specific to VTE-based terminal emulators? (Though this wouldn't explain issues with macOS terminals.)

from textual.

for more macOS terminal emulators:
issue can be reproduced on Hyper, but not on iTerm2 and Terminal.app

from textual.

I can't seem to reproduce it at all with the latest Textual (on macOS).

from textual.

Actually, I did manage to reproduce it after a few attempt on Hyper. This should help me track it down!

from textual.