[GH-ISSUE #332] It's possible to accidentaly quit the application while trying to quit the audio analysis screen #136

New issue

Closed

opened 2026-02-28 14:47:18 +03:00 by kerem · 3 comments

kerem commented

2026-02-28 14:47:18 +03:00

Owner

Originally created by @ericonr on GitHub (Mar 11, 2020).
Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/332

As mentioned in #322

When I press v to open the audio visualizer, if I press q before it loads the visualizer, the quit action is passed to whatever context I'm in, meaning it can even close the application. Testing in the previous version, pressing q before the visualizer opened just means that the visualizer will quickly flash on the screen, because it's closed right after.

It still happens in latest master c0adca85.

Originally created by @ericonr on GitHub (Mar 11, 2020). Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/332 As mentioned in #322 >When I press `v` to open the audio visualizer, if I press `q` before it loads the visualizer, the quit action is passed to whatever context I'm in, meaning it can even close the application. Testing in the previous version, pressing `q` before the visualizer opened just means that the visualizer will quickly flash on the screen, because it's closed right after. It still happens in latest master `c0adca85`.

kerem

2026-02-28 14:47:18 +03:00

closed this issue
added the
good first issue
label

kerem commented

2026-02-28 14:47:19 +03:00

Author

Owner

@Rigellute commented on GitHub (Mar 11, 2020):

Thanks for reporting @ericonr.

This highlights a larger issue - async navigation.

To fix these problems, I think we should eagerly navigate to a screen before the network request has finished. Some screens already work like this.

If anyone wants to contribute, try to find places where app.push_navigation_stack(...) is invoked after some await. Ideally, these navigation events should not happen within network.rs, but rather at the call site of app.dispatch (in app.rs for example).

You might encounter UI problems with this, however. To fix these, we need to have a fallback UI for when the data is not ready/not present.

@Rigellute commented on GitHub (Mar 11, 2020): Thanks for reporting @ericonr. This highlights a larger issue - async navigation. To fix these problems, I think we should eagerly navigate to a screen before the network request has finished. Some screens already work like this. If anyone wants to contribute, try to find places where `app.push_navigation_stack(...)` is invoked _after_ some `await`. Ideally, these navigation events should not happen within `network.rs`, but rather at the call site of `app.dispatch` (in `app.rs` for example). You might encounter UI problems with this, however. To fix these, we need to have a fallback UI for when the data is not ready/not present.

kerem commented

2026-02-28 14:47:19 +03:00

Author

Owner

@ericonr commented on GitHub (Apr 9, 2020):

@Rigellute have you noticed this issue anywhere else? Otherwise I believe I can close it already.

@ericonr commented on GitHub (Apr 9, 2020): @Rigellute have you noticed this issue anywhere else? Otherwise I believe I can close it already.

kerem commented

2026-02-28 14:47:19 +03:00

Author

Owner

@Rigellute commented on GitHub (Apr 13, 2020):

Not noticed this anywhere else, will close.

Thanks @ericonr 👍

@Rigellute commented on GitHub (Apr 13, 2020): Not noticed this anywhere else, will close. Thanks @ericonr 👍

kerem referenced this issue

2026-02-28 14:48:18 +03:00

[GH-ISSUE #732] Little different than the #136 issue. #293