Read-only session mode to prevent accidentally killing a long-lived process #9703

@KalleOlaviNiemitalo commented on GitHub (Jul 20, 2020):

This seems related to pinning tabs (https://github.com/microsoft/terminal/issues/5969) but here I don't care about automatically restarting the long-lived processes, as the work would have been lost already.

@KalleOlaviNiemitalo commented on GitHub (Jul 20, 2020): This seems related to pinning tabs (<https://github.com/microsoft/terminal/issues/5969>) but here I don't care about automatically restarting the long-lived processes, as the work would have been lost already.

claunia commented

@DHowett commented on GitHub (Jul 27, 2020):

You know what, I actually like this idea. Locked sessions or something.
I was going to close it in favor of the "are you sure you want to close? this is running ROBOCOPY.EXE!" prompt, but pinned locked tabs are a pretty cool idea.

@DHowett commented on GitHub (Jul 27, 2020): You know what, I actually like this idea. Locked sessions or something. I was going to close it in favor of the "are you sure you want to close? this is running ROBOCOPY.EXE!" prompt, but pinned locked tabs are a pretty cool idea.

claunia commented

@KalleOlaviNiemitalo commented on GitHub (Jul 29, 2020):

https://github.com/microsoft/terminal/issues/6372 is another feature request for long-lived noninteractive processes. These could be useful together but I don't think the implementations would have anything in common.

@KalleOlaviNiemitalo commented on GitHub (Jul 29, 2020): <https://github.com/microsoft/terminal/issues/6372> is another feature request for long-lived noninteractive processes. These could be useful together but I don't think the implementations would have anything in common.

claunia commented

@Don-Vito commented on GitHub (Jan 20, 2021):

@DHowett, @zadjii-msft - I have a PoC. Still not pushing as it is pretty dirty and doesn't handle all scenarios. Please let me know if UX makes sense:

@Don-Vito commented on GitHub (Jan 20, 2021): @DHowett, @zadjii-msft - I have a PoC. Still not pushing as it is pretty dirty and doesn't handle all scenarios. Please let me know if UX makes sense: ![ReadOnlyTabs](https://user-images.githubusercontent.com/4639110/105116601-bb2fbf80-5ad3-11eb-852d-648b1516a83f.gif)

claunia commented

@zadjii-msft commented on GitHub (Jan 20, 2021):

wow holy crap. That's like, the whole thing!

I think the only thing I'm not positive on is the "If you try to close the window while one pane is read-only, we close all the non-read-only tabs, then prompt for the closing of the read-only pane". ~~In my (very subjective) opinion, the "close readonly tab" warning would supersede the "close all tabs" warning and we'd only display one warning~~.

You know what, I've watched this gif like 8 times while typing this up and I think it's great as it is. I guess in my head I was trying to reconcile that warning with all the scenarios from #6549 - in all those I was still expecting only one dialog. This scenario though kinda necessitates a secondary dialog just for closing the read-only pane, regardless of the confirmClose... settings.

Lemme cycle this through to the team and see if they have other feedback 😄.

@zadjii-msft commented on GitHub (Jan 20, 2021): wow holy crap. That's like, the whole thing! I think the only thing I'm not _positive_ on is the "If you try to close the window while one pane is read-only, we close all the non-read-only tabs, _then_ prompt for the closing of the read-only pane". ~~In my (very subjective) opinion, the "close readonly tab" warning would supersede the "close all tabs" warning and we'd only display one warning~~. You know what, I've watched this gif like 8 times while typing this up and I think it's great as it is. I guess in my head I was trying to reconcile that warning with all the scenarios from #6549 - in all those I was still expecting only _one_ dialog. This scenario though kinda necessitates a secondary dialog just for closing the read-only pane, regardless of the `confirmClose...` settings. Lemme cycle this through to the team and see if they have other feedback 😄.

claunia commented

@KalleOlaviNiemitalo commented on GitHub (Jan 20, 2021):

I wonder if ShutdownBlockReasonCreate would make sense here. Perhaps not, if the user has an SSH connection in the Windows Terminal session and runs tmux or screen on the server.

@KalleOlaviNiemitalo commented on GitHub (Jan 20, 2021): I wonder if [ShutdownBlockReasonCreate](<https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-shutdownblockreasoncreate> "ShutdownBlockReasonCreate function (winuser.h) - Win32 apps | Microsoft Docs") would make sense here. Perhaps not, if the user has an SSH connection in the Windows Terminal session and runs `tmux` or `screen` on the server.

claunia commented

@zadjii-msft commented on GitHub (Jan 20, 2021):

@KalleOlaviNiemitalo Probably not, since there's not a reliable way for a client application to get at the HWND of the Terminal (and we're not about to provide one either). You've called out the exact reason why - it's not going to make sense in ssh sessions, or sessions where the Windows Terminal isn't the end terminal application. So I'd rather not open a door that's not going to work 90% of the time.

@zadjii-msft commented on GitHub (Jan 20, 2021): @KalleOlaviNiemitalo Probably not, since there's not a reliable way for a client application to get at the HWND of the Terminal (and we're not about to provide one either). You've called out the exact reason why - it's not going to make sense in ssh sessions, or sessions where the Windows Terminal isn't the end terminal application. So I'd rather not open a door that's _not going to work 90% of the time_.

claunia commented

@KalleOlaviNiemitalo commented on GitHub (Jan 20, 2021):

I meant Windows Terminal itself could call ShutdownBlockReasonCreate when the user enables read-only mode in a session. On the basis that, if the user does not want to terminate processes in the session by closing a tab in Windows Terminal, then the user probably does not want to terminate them by shutting down Windows, either. In the ssh + tmux scenario though, closing the tab or shutting down Windows is not really a problem because the remote tmux session can be resumed later, but read-only mode can still be useful for blocking Ctrl+C.

@KalleOlaviNiemitalo commented on GitHub (Jan 20, 2021): I meant Windows Terminal itself could call ShutdownBlockReasonCreate when the user enables read-only mode in a session. On the basis that, if the user does not want to terminate processes in the session by closing a tab in Windows Terminal, then the user probably does not want to terminate them by shutting down Windows, either. In the ssh + tmux scenario though, closing the tab or shutting down Windows is not really a problem because the remote tmux session can be resumed later, but read-only mode can still be useful for blocking Ctrl+C.

claunia commented

@sba923 commented on GitHub (Jan 26, 2021):

Very good idea. Count me in as a tester whenever there's code that implements this.

@sba923 commented on GitHub (Jan 26, 2021): Very good idea. Count me in as a tester whenever there's code that implements this.

claunia commented

@zadjii-msft commented on GitHub (Jan 26, 2021):

Good thing, because there's a PR for it already:

See #8867

@zadjii-msft commented on GitHub (Jan 26, 2021): Good thing, because there's a PR for it already: ![image](https://user-images.githubusercontent.com/18356694/105869403-d0698a00-5fbc-11eb-9746-3763624de75a.png) See #8867

claunia commented

@sba923 commented on GitHub (Jan 26, 2021):

What would be the right route to help testing this? Wait until #8867 gets merged in?

@sba923 commented on GitHub (Jan 26, 2021): What would be the right route to help testing this? Wait until #8867 gets merged in?

claunia commented

@zadjii-msft commented on GitHub (Jan 26, 2021):

I mean, you could wait if you want. If you're ambitious, you could always check out the PR and build it locally. I usually do that with a commandline like:

git fetch origin pull/8867/head:pull/8867 && git checkout pull/8867

@zadjii-msft commented on GitHub (Jan 26, 2021): I mean, you could wait if you want. If you're ambitious, you could always check out the PR and build it locally. I usually do that with a commandline like: ``` git fetch origin pull/8867/head:pull/8867 && git checkout pull/8867 ```

claunia commented

@Don-Vito commented on GitHub (Feb 5, 2021):

I meant Windows Terminal itself could call ShutdownBlockReasonCreate when the user enables read-only mode in a session. On the basis that, if the user does not want to terminate processes in the session by closing a tab in Windows Terminal, then the user probably does not want to terminate them by shutting down Windows, either. In the ssh + tmux scenario though, closing the tab or shutting down Windows is not really a problem because the remote tmux session can be resumed later, but read-only mode can still be useful for blocking Ctrl+C.

@KalleOlaviNiemitalo - Right now I moved forward without invoking ShutdownBlockReasonCreate. I am still hesitating if it is a good idea. We could probably add it as an option to the lock command

{ "command": { "action": "toggleReadOnlyMode", "blockShutdown": true }}

If you like the idea, probably we can create a follow up task.

@Don-Vito commented on GitHub (Feb 5, 2021): > > > I meant Windows Terminal itself could call ShutdownBlockReasonCreate when the user enables read-only mode in a session. On the basis that, if the user does not want to terminate processes in the session by closing a tab in Windows Terminal, then the user probably does not want to terminate them by shutting down Windows, either. In the ssh + tmux scenario though, closing the tab or shutting down Windows is not really a problem because the remote tmux session can be resumed later, but read-only mode can still be useful for blocking Ctrl+C. @KalleOlaviNiemitalo - Right now I moved forward without invoking `ShutdownBlockReasonCreate`. I am still hesitating if it is a good idea. We could probably add it as an option to the lock command ``` { "command": { "action": "toggleReadOnlyMode", "blockShutdown": true }} ``` If you like the idea, probably we can create a follow up task.

claunia commented

@DHowett commented on GitHub (Feb 5, 2021):

(I'm in love with this feature. It's so cool.)

@DHowett commented on GitHub (Feb 5, 2021): (I'm in love with this feature. It's so cool.)

claunia commented

@KalleOlaviNiemitalo commented on GitHub (Feb 5, 2021):

@Don-Vito I think it's best not to call ShutdownBlockReasonCreate now. Minimize the risk of surprising effects.

(I assume ShutdownBlockReasonCreate has no effect on whether Microsoft Store can forcefully terminate the app to install updates.)

@KalleOlaviNiemitalo commented on GitHub (Feb 5, 2021): @Don-Vito I think it's best not to call ShutdownBlockReasonCreate now. Minimize the risk of surprising effects. (I assume ShutdownBlockReasonCreate has no effect on whether Microsoft Store can forcefully terminate the app to install updates.)

claunia commented