No Window Close Confirmation When Closing Last Window

[atomdmac]

Describe the bug
Closing the last window in a tab does not prompt the user with a confirmation message even if confirm_os_window_close 1 is set.

To Reproduce
Steps to reproduce the behavior:

• Ensure that confirm_os_window_close 1 is set in your kitty.conf
• Open a Kitty tab with a single window in it
• Issue a close_window command
• Notice that the OS window closes without showing a confirmation message

Screenshots
N / A

Environment details

kitty 0.23.1 created by Kovid Goyal
Darwin 18.7.0 Darwin Kernel Version 18.7.0: Mon May  3 20:41:19 PDT 2021; root:xnu-4903.278.68~1/RELEASE_X86_64 x86_64
ProductName:	Mac OS X ProductVersion:	10.14.6 BuildVersion:	18G9216
Loaded config files:
  /Users/USER_NAME/.config/kitty/kitty.conf

Config options different from defaults:
confirm_os_window_close            1
enable_audio_bell                  False
enabled_layouts                    ['tall:bias=50;full_size=1;mirrored=false']
font_family                        Hasklug NF, Fallback
font_size                          14.0
macos_quit_when_last_window_closed True
scrollback_lines                   4000
tab_bar_edge                       1
tab_bar_style                      slant
visual_bell_duration               0.25
window_border_width                (0, 'pt')
window_margin_width                FloatEdges(left=2.5, top=2.5, right=2.5, bottom=2.5)
Added shortcuts:
	ctrl+f KeyAction('launch', ('--type=overlay', '--stdin-source=@screen_scrollback', '/usr/local/bin/fzf', '--no-sort', '--no-mouse', '--exact', '-i'))
	cmd+d KeyAction('detach_tab', ('ask',))
	cmd+left KeyAction('neighboring_window', ('left',))
	cmd+right KeyAction('neighboring_window', ('right',))
Changed shortcuts:
	cmd+1 KeyAction('goto_tab', (1,))
	cmd+2 KeyAction('goto_tab', (2,))
	cmd+3 KeyAction('goto_tab', (3,))
	cmd+4 KeyAction('goto_tab', (4,))
	cmd+5 KeyAction('goto_tab', (5,))
	cmd+6 KeyAction('goto_tab', (6,))
	cmd+7 KeyAction('goto_tab', (7,))
	cmd+8 KeyAction('goto_tab', (8,))
	cmd+9 KeyAction('goto_tab', (9,))
	cmd+n KeyAction('new_os_window_with_cwd')
	cmd+up KeyAction('neighboring_window', ('top',))
	cmd+down KeyAction('neighboring_window', ('bottom',))
Colors:
	background                         #333333   

Additional context
Try to reproduce the problem with kitty --config NONE if you cannot then post a minimal kitty.conf that reproduces the problem. If the problem involves interaction with some other terminal program post a minimal config for that program to reproduce the problem as well.

[kovidgoyal]

The option doesn't apply to closing individual windows, whether they are
last or not. Only to closing window groups, such as a tab or an OS
Window or the entire application. It would be pretty strange is closing
a window pops up a confirmation just because it is the last window in a
tab

[atomdmac]

@kovidgoyal The issue that I'm describing is one where invoking close_window on the last open window in a tab does not trigger the confirmation. I agree that it wouldn't make sense to trigger confirmation for every closed window; just the last one in the tab.

[page-down]

In fact, conceptually, using close_tab to close a tab with only one window means the same thing as using close_window to close a window in a tab with only one window.

Are you sure you want to close this tab, it has 1 windows running?

When set to 1 and when closing the last one, the purpose of this config option is all to protect the one from being closed by accident.

Does this make sense to you?

---

I found that the method with @ ac in tabs.py is not executed when I press ctrl+shift+w, but the close_window in boss.py is run instead. If there is a problem, is there any way to avoid similar conflicts in the future? Or is this by design?

# boss.py
class Boss:
    ...
    def close_window(self, window: Optional[Window] = None) -> None:
        ...

# tabs.py
class Tab:
    ...
    @ac('win', 'Close the currently active window')
    def close_window(self) -> None:
        ...

[kovidgoyal]

Yes, close_window closes a window, unconditionally. Why would it ask for
a confirmation just because the window being closed is the last one in a
tab? close_window closes exactly one window. confirm_os_window_close
is documented to ask for confirmation when closing tabs/os windows, not
individual windows.

One could argue that it should apply to close_window as well when set to
1 but that's a feature not a bug and i need a use case for that feature.

[atomdmac]

@kovidgoyal After giving it some more thought, I agree that the current behavior makes sense. I've been running into trouble with closing windows accidentally with running processes (as close_tab is bound to cmd+w) but I think that could possibly be avoided by using a 3-key binding instead. Thanks for your feedback and patience.

[page-down]

From a user perspective, I can understand that. They think that this configuration, regardless of any situation that causes the os window to close in less than this number of windows, should prompt.

"confirm_os_window_close 1"

It even contains the use of the method ctrl+d which causes this os window or tab to close. The reason for this is that they consider the environment variables, pwd, etc., to be of value. They will mistakenly press ctrl+d, and they expect this configuration to be the last line of defense for their stubby fingers.

And you are talking about specific functions and implementations from the author's point of view, and what each different command represents.

The above is just my personal understanding and opinion of the situation. Each side has its own validity.

[kovidgoyal]

On Fri, Nov 05, 2021 at 11:03:43AM -0700, page-down wrote: From a user perspective, I can understand that. They think that this configuration, regardless of any situation that causes the os window to close in less than this number of windows, should prompt. "confirm_os_window_close 1" It even contains the use of the method ctrl+d which causes this os window or tab to close. The reason for this is that they consider the environment variables, pwd, etc., to be of value. They will mistakenly press ctrl+d, and they expect this configuration to be the last line of defense for their stubby fingers.

Umm I dont see why they would expect that. Nowhere does this option say it prevents a window from closing in any an all circumstances.

[page-down]

Yes, maybe in the future someone will ask such a ridiculous question. In the example above, if a program in window decides to quit on its own, e.g. by receiving an eof from the user.
terminal cannot stop it. If you don't mind, I'll try to update the configuration notes. Maybe tomorrow.

Regarding my question about @ ac mentioned above, why are the methods in tabs.py not executed? Instead, it is running boss's. Is this my misunderstanding?

[kovidgoyal]

On Fri, Nov 05, 2021 at 11:46:26AM -0700, page-down wrote: Yes, maybe in the future someone will ask such a ridiculous question. In the example above, if a program in window decides to quit on its own, e.g. by receiving an eof from the user. terminal cannot stop it. If you don't mind, I'll try to update the configuration notes. Maybe tomorrow. Regarding my question about @ ac mentioned above, why are the methods in tabs.py not executed? Instead, it is running boss's. Is this my misunderstanding?

The order for finding a function is 1) boss.py 2) the active tab object 3)the active window object See dispatch_action() for details.