mirror of
https://github.com/mum4k/termdash.git
synced 2026-04-27 03:15:55 +03:00
[GH-ISSUE #210] App exit after zooming out #117
Labels
No labels
bug
cleanup
enhancement
enhancement
enhancement
good first issue
help wanted
help wanted
pull-request
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/termdash#117
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @keithknott26 on GitHub (May 21, 2019).
Original GitHub issue: https://github.com/mum4k/termdash/issues/210
Originally assigned to: @keithknott26 on GitHub.
@mum4k ,
After changing termdash to use key.keyboardEsc to quit the app, I noticed that when the app is left running for a long time (5+ hours) you can exit out of it by zooming into the linechart and quickly zooming out. I've tested this using the standard trackpad for my Macbook and noticed that when the application exits there is no panic, I do see a large number of escape characters printed to the screen, and my terminal stays in alternate screen mode. Scrolling up or down on the trackpad after the application exists, results in printing the escape characters to the screen. The only way to restore the terminal functionality is to type reset.
Could this be a bug in termdash? I've attached a screenshot of the output once the app exits. Since I can replicate this very easily, I'm hoping you might be able to recommend if I should place some debug lines in strategic locations, log to a file locally, or if providing the output of kill -ABRT is sufficient to debug this.
@mum4k commented on GitHub (May 21, 2019):
Hey @keithknott26,
thanks for reporting this. It might be that termdash (or termbox) incorrectly interprets one of the mouse events as the Esc key. But something else could be happening also, we should investigate this.
One important question is - does this only happen after running for 5+ hours? Or can you reproduce it without the long run. If it only happens after running for a long time, it might indicate a leak somewhere in the event distribution system.
To confirm the theory that a mouse event is interpreted as an Esc key, we would modify the demo. We could register a custom mouse subscriber and modify the custom keyboard subscriber so that they write all received events to a buffer for later investigation. The registration:
github.com/mum4k/termdash@b60c1c5fb0/termdash.go (L74-L90)Example of the new mouse and modified keyboard subscribers is below. Note that this probably contains some errors / typos as I didn't test it.
Feel free to adjust what is logged so that we have all the needed information. Is this something you could try out?
Please let me know if you would prefer I put this together in some separate branch and share the code with you instead.
@keithknott26 commented on GitHub (Jun 6, 2019):
How would you go about fixing this piece, the complier doesn't like this line
ioutil.WriteFile("/tmp/eventlog.txt", []byte{buff.String()}, 0644)"Cannot use buff.String() as type byte in array or slice literal"
I can reproduce this fairly easily the app just needs some soak time. I noticed it happens when you scroll up or down very fast after the app has been lagging doing a bunch of work for a few hours.
**Edit, nevermind I see it.. it needs ()'s instead of {}'s. Should have the log back shortly.
@keithknott26 commented on GitHub (Jun 6, 2019):
Let me know if this helps or if you'd like me to try another approach to capture the necessary debug logging.
Another attempt resulted in the following (note i didn't hit ESC)
got keyboard event with key: KeyEsc (-50) rune: �And another attempt
Seems to be easier to replicate this on a machine that's under load and responding slowly. Also I noticed that I actually don't need to wait 5 hours, I can replicate it right away by quickly scrolling up and down on the standard OSX trackpad, and a standard USB mouse with scrollwheel.
Here is some other stuff I thought might help:
Terminal.App for OSX 10.14.5
Standard "Basic" Theme , SF Mono Regular 11 font
echo $TERM;
xterm-256color
Scroll Alternate screen [x] enabled
Delete sends Control-H [ ] disabled
Escape non-ASCII input with Control-V [ ] disabled
Paste newlines as carriage returns. [x] enabled
Allow VT100 application keypad mode. [x] enabled
Scroll to bottom on input. [x] enabled
Text Encoding: UTF-8
@mum4k commented on GitHub (Jun 6, 2019):
Thanks a lot Keith.Sorry, the ioutil error was actually my typo, it should have been:
Notice the regular parenthesis (i.e. type conversion) as opposed to the curly ones (i.e. type literal creation).
@mum4k commented on GitHub (Jun 6, 2019):
So it looks like Termdash actually gets the keyboard Esc events. The next step would be to figure out if this is a bug in Termdash or upstream.
We should move the logging up to where Termdash pulls terminal events out of Termbox, i.e. here:
github.com/mum4k/termdash@68bf0566e6/terminal/termbox/termbox.go (L142)We probably want to log the output of
tbx.PollEvent()into a file.Do note that we might need to be creative in how we log the output of
tbx.PollEvent(), since the TermboxEventtype doesn't implement fmt.Stringer. So we might need to print them as:@keithknott26 commented on GitHub (Jun 6, 2019):
Jakub,
I took your suggestion and moved the logging up to termbox.go, I was able to capture the events which lead up to the application exit and have included them below. It looks like scrolling up / down results in some variation of 'KeyEsc[<6' or 'KeyEsc[<' 'KeyEsc<64;' or 'KeyEsc<64;6' depending on which direction I'm going on the Macbook Pro trackpad. Could the event system be aware of these key combinations and ensure they're always taken in chunks instead of interpreted individually somehow?
I should mention I can replicate this on two different terminal programs, Terminal.App and iTerm2
The widget gets this:
Termbox.Go Gets:
@mum4k commented on GitHub (Jun 7, 2019):
Thanks again @keithknott26, it is good to have a confirmation that these are legitimate events coming from the terminal.
Before we look for workarounds like event combining or preprocessing, it might be a good idea to get a better understanding of why this is happening. Assuming that you still have some time to dig deeper, here are a couple of questions worth investigating:
Feel free to suggest anything else that comes to mind.
@mum4k commented on GitHub (Mar 7, 2020):
Closing as obsolete, please reopen if this still needs attention.