If eg the settings dialog or newly added traceroute confirmation dialog are on screen when we trigger a call to draw_messages_window(), the messages window will be drawn over top of the dialing, making it invisible, but the invisible dialog still gets/handles button presses.
If eg the settings dialog or newly added traceroute confirmation dialog are on screen when we trigger a call to draw_messages_window(), the messages window will be drawn over top of the dialing, making it invisible, but the invisible dialog still gets/handles button presses.
<!-- github-sync-id:2793606923 -->
I'm thinking we add a field to ChatUIState such as popup_win that tracks if a the traceroute result or menu items etc are in the foreground, and if not None we call to redraw that window after draw_message_window()
I'm thinking we add a field to ChatUIState such as `popup_win` that tracks if a the traceroute result or menu items etc are in the foreground, and if not None we call to redraw that window after draw_message_window()
<!-- github-comment-id:2951922789 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
If eg the settings dialog or newly added traceroute confirmation dialog are on screen when we trigger a call to draw_messages_window(), the messages window will be drawn over top of the dialing, making it invisible, but the invisible dialog still gets/handles button presses.
I'm thinking we add a field to ChatUIState such as
popup_winthat tracks if a the traceroute result or menu items etc are in the foreground, and if not None we call to redraw that window after draw_message_window()Starting to fix this in #214 and subsequent commits. I still need to catch a few window types.
Fixed on my machine. Send bugs.
Dialogs disappearingto Dialogs disappearing