Rich BUG: keyboard not responding after text scroll components are closed, hanging both program and terminal until we quit a-Shell
- Dominant language
- Perl
- Stars
- 3.9k
- Forks
- 213
- Avg merge
- 1m
- Merged PRs (30d)
- 1
Description
Here is another annoying bug that comes out often when using RICH.
Using any textual or rich component that uses internal scrolling, like Scrollview, Console.Pager, or CodeBrowser, etc. will cause the following:
- If the function runs in the main thread, the moment we close the module the entire script stop working. Not because of a crash or becouse has frozen, but because the keyboard doesn't write anything more. It is like lost. Is not clear if the issue is that the keyboard input is sent elswhere or because the keyboard is not writing at all. The input command in python stll blinks the cursor waiting, but nothing is written and to close the script one has to kill a-Shell.
- if the function runs in a different thread, the stop to the keyboard or screen (still not clear) happens the same but the module before hanging gives the following error about signal not running in secondary threads:
```
Opening book..
Waiting for the thread to finish task...
╭───────────────────────────────────── Traceback (most recent call last) ─────────────────────────────────────╮
│ /var/mobile/Containers/Data/Application/5896FDC4-A93C-4F95-B6E0-41EAF01171C3/Library/lib/python3.11/site-pa │
│ ckages/textual/app.py:2076 in _process_messages │
│ │
│ 2073 │ │ │ ) │
│ 2074 │ │ │ │
│ 2075 │ │ │ if not self._exit: │
│ ❱ 2076 │ │ │ │ driver.start_application_mode() │
│ 2077 │ │ │ │ try: │
│ 2078 │ │ │ │ │ with redirect_stdout(self._capture_stdout): │
│ 2079 │ │ │ │ │ │ with redirect_stderr(self._capture_stderr): │
│ │
│ ╭──────────────────────────────────────────────── locals ─────────────────────────────────────────────────╮ │
│ │ css = 'App {\n background: $background;\n color: $text;\n }\n\n │ │
│ │ *:disabl'+43 │ │
│ │ driver = │ │
│ │ driver_class = │ │
│ │ error = ValueError('signal only works in main thread of the main interpreter') │ │
│ │ headless = False │ │
│ │ load_event = Load() │ │
│ │ message_hook = None │ │
│ │ path = '/var/mobile/Containers/Data/Application/5896FDC4-A93C-4F95-B6E0-41EAF01171C3/L… │ │
│ │ ready_callback = None │ │
│ │ run_process_messages = .run_process_messages at 0x12a6c1c60> │ │
│ │ self = CodeBrowser(title='CodeBrowser', classes={'-dark-mode'}) │ │
│ │ terminal_size = None │ │
│ │ tie_breaker = -1 │ │
│ ╰─────────────────────────────────────────────────────────────────────────────────────────────────────────╯ │
│ │
│ /var/mobile/Containers/Data/Application/5896FDC4-A93C-4F95-B6E0-41EAF01171C3/Library/lib/python3.11/site-pa │
│ ckages/textual/drivers/linux_driver.py:136 in start_application_mode │
│ │
│ 133 │ │ def on_terminal_resize(signum, stack) -> None: │
│ 134 │ │ │ send_size_event() │
│ 135 │ │ │
│ ❱ 136 │ │ signal.signal(signal.SIGWINCH, on_terminal_resize) │
│ 137 │ │ │
│ 138 │ │ self.write("\x1b[?1049h") # Alt screen │
│ 139 │
│ │
│ ╭──────────────────────────────────────────────── locals ─────────────────────────────────────────────────╮ │
│ │ loop = <_UnixSelectorEventLoop running=True closed=False debug=False> │ │
│ │ on_terminal_resize = .on_terminal_resize at │ │
│ │ 0x12a6c0d60> │ │
│ │ self = │ │
│ │ send_size_event = .send_size_event at │ │
│ │ 0x12a6c1ee0> │ │
│ ╰─────────────────────────────────────────────────────────────────────────────────────────────────────────╯ │
│ │
│ /private/var/containers/Bundle/Application/87621026-4603-46BA-9B34-2EE4014FF869/a-Shell.app/Library/lib/pyt │
│ hon3.11/signal.py:56 in signal │
│ │
│ 53 │
│ 54 @_wraps(_signal.signal) │
│ 55 def signal(signalnum, handler): │
│ ❱ 56 │ handler = _signal.signal(_enum_to_int(signalnum), _enum_to_int(handler)) │
│ 57 │ return _int_to_enum(handler, Handlers) │
│ 58 │
│ 59 │
│ │
│ ╭─────────────────────────────────────────────── locals ───────────────────────────────────────────────╮ │
│ │ handler = .on_terminal_resize at 0x12a6c0d60> │ │
│ │ signalnum = │ │
│ ╰──────────────────────────────────────────────────────────────────────────────────────────────────────╯ │
╰─────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
ValueError: signal only works in main thread of the main interpreter
Hello, World!
YOU ARE EXPERIENCING THE MYSTERIOUS INVISIBLE WRITING BUG. PROGRAM IS UNRESPONSIVE.
What is [i]your[/i] [bold red]name[/]? :smiley:
```
I noticed another thing: somehow you need to load a long txt document, at least 2-3000 chars for it to happens. I don't know if this happen to be linked with the screen buffers or secondary layers sizes (maybe the text is written somewhere outside the screen?) but it is surely an issue. Since it depends but how each rich or textual component handle the off screen texts and by how big the text is, and by the user settings for the terminal size of a-Shell, it is not easy to replicate in a deterministic way, but it happens pretty often.
Sadly, many of the awesome progress meters, popup completion widgets, changing rich components, percentage completition bars, scroll tables, headers and footers, input panels, and other similar components are still non working in a-Shell or are seriously messed up graphically. At least 70% of the rich and textual functionalities are non working. Being the console of a-Shell a simulated replica of the original, of course supporting a-Shell completely would be a big deal, but being so central and transversal to so many python packages, I think it would be wise to put it among the priorities. Thanks.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.