pop_screen() triggering randomly after hoovering buttons under heavy load

[matkudela]

I noticed strange behavior while hoovering very fast on many buttons. pop_screen is being triggered ramdomly only under heavy load on my computer (used stress command). Tried same thing with push_screen but works fine.
Example used in video:

from __future__ import annotations

from textual import on
from textual.app import App, ComposeResult
from textual.binding import Binding
from textual.screen import Screen, ScreenResultType
from textual.widgets import Button
from textual.containers import Horizontal


class MyApp(App):

    def compose(self) -> ComposeResult:
        yield Button("next screen", variant="success")

    @on(Button.Pressed)
    def next_screen(self):
        self.app.push_screen(Screen2())


class Screen2(Screen[ScreenResultType]):
    BINDINGS = [Binding("escape", "other_screen", "next")]

    def compose(self) -> ComposeResult:
        with Horizontal():
            yield Button("1", variant="success")
            yield Button("2", variant="primary")
            yield Button("3", variant="error")
            yield Button("4", variant="success")
            yield Button("5", variant="primary")
            yield Button("6", variant="error")

    def action_other_screen(self):
        self.app.pop_screen()

MyApp().run()

Since github is accepting files under 10MB im linking video: https://drive.google.com/file/d/1qG4SCLF-0-HXDOMNLBCrGF4lFM7Lxlxj/view?usp=drivesdk

[github-actions]

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

• How can I select and copy text in a Textual app?
• How do I center a widget in a screen?

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

[davep]

My initial reaction to this would be that it's unlikely that it's a case of "pop_screen() triggering randomly after hoovering buttons under heavy load" and very possibly a case of an instance of escape being detected and processed as keyboard input.

[matkudela]

You are right, just tested it.

[willmcgugan]

Can you paste the result of textual diagnose please.

[matkudela]

Textual Diagnostics

Versions

Name	Value
Textual	0.62.0
Rich	13.7.0

Python

Name	Value
Version	3.10.12
Implementation	CPython
Compiler	GCC 11.4.0
Executable	/home/dev/.pyenv/versions/3.10.12/envs/clive_venv/bin/python3.10

Operating System

Name	Value
System	Linux
Release	6.5.0-15-generic
Version	#15~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Jan 12 18:54:30 UTC 2

Terminal

Name	Value
Terminal Application	Terminator
TERM	xterm-256color
COLORTERM	truecolor
FORCE_COLOR	Not set
NO_COLOR	Not set

Rich Console options

Name	Value
size	width=105, height=56
legacy_windows	False
min_width	1
max_width	105
is_terminal	True
encoding	utf-8
max_height	56
justify	None
overflow	None
no_wrap	False
highlight	None
markup	None
height	None

[willmcgugan]

@matkudela Could you try running with TEXTUAL_DEBUG=1 to reproduce the issue, then sending us the keys.log file that it generates.

[matkudela]

You mean opening textual keys app?

If no where I can find the logs?

[willmcgugan]

run your app with TEXTUAL_DEBUG=1 python myapp.py Reproduce the issue and exit. You should find keys.log in the working directory.

[matkudela]

keys.log

[willmcgugan]

You have a slightly older version of Textual. Would you mind upgrading to the latest, and repeating the test?

[matkudela]

Upgraded to 0.65.2, works same way keys.log

[willmcgugan]

I'm not certain if this will fix it, but please try 0.66.0

[matkudela]

Didn't help.

[willmcgugan]

Please try Textual 0.71.0

[github-actions]

Don't forget to star the repository!

Follow @textualizeio for Textual updates.

[matkudela]

Most of the time works fine but managed to recreate this problem once in 15 minutes of testing.