starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-09-24 07:54:35 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

megathread: Window State Persistence #13417

New Issue
Open
opened 2026-01-31 03:42:07 +00:00 by claunia · 12 comments
claunia commented 2026-01-31 03:42:07 +00:00
Owner
Copy Link

Originally created by @zadjii-msft on GitHub (Apr 13, 2021).

[Original thread: #766] [Spec: {none}] [Initial PR: #10972] [Multiple windows PR: #11083]

This thread is being used to track all the component work for restoring the window state. Additionally related threads:

  • #766 - Restore the layout, position of windows
    • This is partially implemented in #10972
    • #11083 handles this for multiple windows.
  • #961 - Restore the contents of the buffer when resuming a tab.
    • This is not about restoring the process state entirely, since that's impossible. Simply the text content is good enough.
    • Stashing this in JSON doesn't really make sense - imagine SHRT_MAX lines of text + attributes in a json string.
  • #960 - Re-open a recently closed tab
    • This means we shouldn't just discard the terminal control when closing a pane/tab. This is similar to the ctrl+shift+t shortcut in (Chromium) browsers
    • Likely best to wait for #1256 and #5000 to sort themselves out before starting this one.
  • #8841 and #8812 need to merge, so we can properly reflect all these options in the SUI.
  • Alias for commands (#11081)
  • PR #3429 broke PublicTerminalCore.dll on Windows 7 (#6362)
Settings UI Mockup (programmer art warning)

mockup

2.0 Bugs

these are all presuming that #10972 merges basically as is

Originally created by @zadjii-msft on GitHub (Apr 13, 2021). ##### [Original thread: #766] [Spec: {none}] [Initial PR: #10972] [Multiple windows PR: #11083] This thread is being used to track all the component work for restoring the window state. Additionally related threads: * #766 - **Restore the layout, position of windows** * This is partially implemented in #10972 * #11083 handles this for multiple windows. * #961 - Restore the contents of the buffer when resuming a tab. * This is not about restoring the process state entirely, since that's impossible. Simply the text content is good enough. * Stashing this in JSON doesn't _really_ make sense - imagine `SHRT_MAX` lines of text + attributes in a json string. * #960 - **Re-open a recently closed tab** * This means we shouldn't just discard the terminal control when closing a pane/tab. This is similar to the <kbd>ctrl+shift+t</kbd> shortcut in (Chromium) browsers * Likely best to wait for #1256 and #5000 to sort themselves out before starting this one. * #8841 and #8812 need to merge, so we can properly reflect all these options in the SUI. * #11081 * #6362 <details> <summary> Settings UI Mockup (programmer art warning) </summary> ![mockup](https://user-images.githubusercontent.com/18356694/130969227-73eca7ec-3f9b-4c27-be2d-cb68c6ba8f08.png) </details> ### 2.0 Bugs _these are all presuming that #10972 merges basically as is_ * [x] We should wrap this feature up in a Preview-only feature flag (no external community member should have to deal with that) * [x] Opening an elevated window will automatically re-open all the unelevated window state (as elevated!). This is because there are separate monarchs for elevated and unelevated windows. - Elevated windows should probably just participate at all in persist/restore for now. That's okay. We may revisit after https://github.com/microsoft/terminal/projects/5#card-67023745 * [x] How do we persist something like `wt -- cmd.exe`? That won't have a profile, only a `NewTerminalArgs`, that we don't cache at runtime - We've mentioned in team syncs before that we may need to keep the `NewTerminalArgs` around when spawning a * [ ] Same idea with a defterm connection - We won't be able to restore defterm panes _at all_, because we have no idea what profile they were. Right? * [x] How exactly does this work with the `_quake` window? Should that participate in the session restore? Probably, yea. * [x] Window _names_ need to be persisted as well. * [x] Closing the last window with `ClosePane` will clear out any persisted layout. - This is by design * [x] Similarly with closing the last tab by clicking the `x` on the tab itself. Doesn't seem to save the window layout in that case. - This is by design * [x] If you have a profile with a `background`, then the colorscheme will blow away the profile's background on restore. - fixed in #11083 * [x] Terminal doesn't remember maximized, focus, fullscreen states #11426 * [ ] #11639 * [x] #11878 * [ ] #18670 * [ ] #12902 * [ ] #12633 * [ ] The size of a focus mode window is wrong after a session restore. I believe this is actually the same root cause as: - #10730 - as also noted in https://github.com/microsoft/terminal/pull/17066#discussion_r1567425547
claunia added the Product-TerminalIssue-ScenarioArea-Remoting labels 2026-01-31 03:42:07 +00:00
claunia commented 2026-01-31 03:42:08 +00:00
Author
Owner
Copy Link

@Rosefield commented on GitHub (Sep 1, 2021):

Re

How do we persist something like wt -- cmd.exe? That won't have a profile, only a NewTerminalArgs, that we don't cache at runtime

I can answer that concretely, just fine (the TerminalSettings on a control has all of these properties)

{
	...
	"tabLayout" : 
	[
		{
			"action" : "newTab",
			"colorScheme" : "Solarized Dark",
			"commandline" : "cmd.exe",
			"profile" : "Default",
			"startingDirectory" : null,
			"suppressApplicationTitle" : false,
			"tabTitle" : "cmd.exe"
		}
	]
}
@Rosefield commented on GitHub (Sep 1, 2021): Re > How do we persist something like wt -- cmd.exe? That won't have a profile, only a NewTerminalArgs, that we don't cache at runtime I can answer that concretely, just fine (the TerminalSettings on a control has all of these properties) ``` { ... "tabLayout" : [ { "action" : "newTab", "colorScheme" : "Solarized Dark", "commandline" : "cmd.exe", "profile" : "Default", "startingDirectory" : null, "suppressApplicationTitle" : false, "tabTitle" : "cmd.exe" } ] } ```
claunia commented 2026-01-31 03:42:09 +00:00
Author
Owner
Copy Link

@Rosefield commented on GitHub (Sep 4, 2021):

Re

We should wrap this feature up in a Preview-only feature flag (no external community member should have to deal with that)

This is done on 10972 now

Opening an elevated window will automatically re-open all the unelevated window state (as elevated!). This is because there are separate monarchs for elevated and unelevated windows.

I disabled the feature entirely for elevated processes on 11083 in 8ffd314b95

Window names need to be persisted as well.

Was added to 11083 in a93d3b1640
With some minor modification it should be pretty safe to cherry-pick these if necessary.

How exactly does this work with the _quake window? Should that participate in the session restore? Probably, yea.

With just 10972 this is a problem since that is explicitly checking for the existence of only one window remaining. With 11083 the _quake window will be saved just fine, but might lead to confusing users if they closed all of their visible windows and thinking that it saved the last layout. If the quit action is added that just becomes a point of user education that quit is the proper way to close all of their windows and save them. There might be some issues with saving the position/size of the quake window, but there is already special logic to handle _quake so it might just turn out OK magically.

Same idea with a defterm connection - We won't be able to restore defterm panes at all, because we have no idea what profile they were. Right?

Hypothetically this should be the same as the commandline version above in that it saves fine, but as the "Default" profile.

@Rosefield commented on GitHub (Sep 4, 2021): Re > We should wrap this feature up in a Preview-only feature flag (no external community member should have to deal with that) This is done on 10972 now > Opening an elevated window will automatically re-open all the unelevated window state (as elevated!). This is because there are separate monarchs for elevated and unelevated windows. I disabled the feature entirely for elevated processes on 11083 in https://github.com/microsoft/terminal/pull/11083/commits/8ffd314b952b4cc98d3d5e84cce74220353bdeb7 > Window names need to be persisted as well. Was added to 11083 in https://github.com/microsoft/terminal/pull/11083/commits/a93d3b164058ccbe4803b74f62f3a0bda9af5758 With some minor modification it should be pretty safe to cherry-pick these if necessary. > How exactly does this work with the _quake window? Should that participate in the session restore? Probably, yea. With just 10972 this is a problem since that is explicitly checking for the existence of only one window remaining. With 11083 the `_quake` window will be saved just fine, but might lead to confusing users if they closed all of their visible windows and thinking that it saved the last layout. If the `quit` action is added that just becomes a point of user education that `quit` is the proper way to close all of their windows and save them. There might be some issues with saving the position/size of the quake window, but there is already special logic to handle `_quake` so it might just turn out OK magically. > Same idea with a defterm connection - We won't be able to restore defterm panes at all, because we have no idea what profile they were. Right? Hypothetically this should be the same as the commandline version above in that it saves fine, but as the "Default" profile.
claunia commented 2026-01-31 03:42:09 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 7, 2021):

wowow I half-assed a list of showerthoughts of things that might go wrong with this (that could be fixed in post), and the man just goes and fixes/addresses all of them. That's great, thanks!

@zadjii-msft commented on GitHub (Sep 7, 2021): wowow I half-assed a list of showerthoughts of things that might go wrong with this (that could be fixed in post), and the man just goes and fixes/addresses all of them. That's great, thanks!
claunia commented 2026-01-31 03:42:09 +00:00
Author
Owner
Copy Link

@Rosefield commented on GitHub (Sep 20, 2021):

Re

Closing the last window with ClosePane will clear out any persisted layout.
Similarly with closing the last tab by clicking the x on the tab itself. Doesn't seem to save the window layout in that case.

That was deliberate behavior because I took those actions to mean "I don't want to save these tab(s)". If you close all of your tabs in your browser and then re-open the browser it wouldn't have saved anything either. This is yet again a problem that is ameliorated by quit.

@Rosefield commented on GitHub (Sep 20, 2021): Re > Closing the last window with ClosePane will clear out any persisted layout. > Similarly with closing the last tab by clicking the x on the tab itself. Doesn't seem to save the window layout in that case. That was deliberate behavior because I took those actions to mean "I don't want to save these tab(s)". If you close all of your tabs in your browser and then re-open the browser it wouldn't have saved anything either. This is yet again a problem that is ameliorated by `quit`.
claunia commented 2026-01-31 03:42:10 +00:00
Author
Owner
Copy Link

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

Okay, thanks for clearing that up. That makes sense, it was a little unexpected by that's fine so long as we've got it all documented.

@zadjii-msft commented on GitHub (Sep 20, 2021): Okay, thanks for clearing that up. That makes sense, it was a little unexpected by that's fine so long as we've got it all documented.
claunia commented 2026-01-31 03:42:10 +00:00
Author
Owner
Copy Link

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

Another bug (sorry for the very non minimal repro)

        {
            "hidden":false,
            "name" : "Ubuntu",
            "background" : "#2C001E",
            "tabColor": "#2C001E",
            "commandline" : "wsl.exe",
            "colorScheme" : "Builtin Tango Dark",
        }

If you open a tab with that profile, then close the window and have it reopen, the background that's set in the profile (#2C001E) will not be visible, it'll be the one from he scheme

@zadjii-msft commented on GitHub (Sep 20, 2021): Another bug (sorry for the very non minimal repro) ```jsonc { "hidden":false, "name" : "Ubuntu", "background" : "#2C001E", "tabColor": "#2C001E", "commandline" : "wsl.exe", "colorScheme" : "Builtin Tango Dark", } ``` If you open a tab with that profile, then close the window and have it reopen, the `background` that's set in the profile (#2C001E) will not be visible, it'll be the one from he scheme
claunia commented 2026-01-31 03:42:10 +00:00
Author
Owner
Copy Link

@Rosefield commented on GitHub (Sep 20, 2021):

Added to #11083 (until that is merged I'll be making bug fixes there)

@Rosefield commented on GitHub (Sep 20, 2021): Added to #11083 (until that is merged I'll be making bug fixes there)
claunia commented 2026-01-31 03:42:11 +00:00
Author
Owner
Copy Link

@ykoehler commented on GitHub (Oct 15, 2021):

In the same idea, I would like to be able to "obtain" the wt command to execute to open up my tab exactly the same way (with same panes and panes size, etc). From there I could paste that into a shortcut icon and create a different layout for each icon to open with. So if somehow we could dump a wt command output that I re-run and get a window with the same tab/pane and size that would be appreciated, in this case, I do not care about running commands in those, but I get you would have to support it.

@ykoehler commented on GitHub (Oct 15, 2021): In the same idea, I would like to be able to "obtain" the wt command to execute to open up my tab exactly the same way (with same panes and panes size, etc). From there I could paste that into a shortcut icon and create a different layout for each icon to open with. So if somehow we could dump a wt command output that I re-run and get a window with the same tab/pane and size that would be appreciated, in this case, I do not care about running commands in those, but I get you would have to support it.
claunia commented 2026-01-31 03:42:11 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 23, 2021):

I'm stashing this here because it was weird, but not because I think we need to do anything about it.

I restarted after an update and found two of these entries in my state.json:


			"tabLayout" : 
			[
				{
					"action" : "newTab",
					"commandline" : "\"C:\\Windows\\System32\\cmd.exe\" /q /c rmdir /s /q \"C:\\Users\\migrie\\AppData\\Local\\Microsoft\\OneDrive\\21.234.1111.0001\"",
					"profile" : "cmd",
					"startingDirectory" : "C:\\Users\\migrie",
					"suppressApplicationTitle" : false,
					"tabTitle" : "C:\\Windows\\System32\\cmd.exe"
				}
			]

(The other was for 21.226.1101.0001, but otherwise idendical)

Both of them opened like
image

Which is quite curious. Presumably these are defterm windows that got captured by the Terminal, but also the Terminal must have been closed at just the right time that these were open.

@zadjii-msft commented on GitHub (Nov 23, 2021): I'm stashing this here because it was weird, but not because I think we need to do anything about it. I restarted after an update and found two of these entries in my `state.json`: ```json "tabLayout" : [ { "action" : "newTab", "commandline" : "\"C:\\Windows\\System32\\cmd.exe\" /q /c rmdir /s /q \"C:\\Users\\migrie\\AppData\\Local\\Microsoft\\OneDrive\\21.234.1111.0001\"", "profile" : "cmd", "startingDirectory" : "C:\\Users\\migrie", "suppressApplicationTitle" : false, "tabTitle" : "C:\\Windows\\System32\\cmd.exe" } ] ``` (The other was for `21.226.1101.0001`, but otherwise idendical) Both of them opened like ![image](https://user-images.githubusercontent.com/18356694/143017048-5ad9a1ce-d2ec-458d-ba1c-ae8534d127e1.png) Which is quite curious. Presumably these are defterm windows that got captured by the Terminal, but also the Terminal must have been closed at just the right time that these were open.
claunia commented 2026-01-31 03:42:11 +00:00
Author
Owner
Copy Link

@Rosefield commented on GitHub (Feb 6, 2022):

What should still be done in order to enable persisted layouts for stable builds? I'm not sure if there is any telemetry for how often the feature is enabled / crashes related to it. My n=1 data says that it has been working quite well :).

@Rosefield commented on GitHub (Feb 6, 2022): What should still be done in order to enable persisted layouts for stable builds? I'm not sure if there is any telemetry for how often the feature is enabled / crashes related to it. My n=1 data says that it has been working quite well :).
claunia commented 2026-01-31 03:42:11 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 7, 2022):

That's a great question. I'm personally happy with it, I kinda forgot it was preview only. IMO we should have this in 1.12 Stable, but I'll discuss with the team.

@zadjii-msft commented on GitHub (Feb 7, 2022): That's a great question. I'm personally happy with it, I kinda forgot it was preview only. IMO we should have this in 1.12 Stable, but I'll discuss with the team.
claunia commented 2026-01-31 03:42:11 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 7, 2022):

Okay, team consensus. We're gonna move this to stable in 1.14. Just give it a little more time to bake. Overall, we're really happy with it, you did a great job ☺️

@zadjii-msft commented on GitHub (Feb 7, 2022): Okay, team consensus. We're gonna move this to stable in 1.14. Just give it a little more time to bake. Overall, we're really happy with it, you did a great job ☺️
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Remoting Issue-Scenario Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#13417
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?