megathread: Window State Persistence

[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:

Enable Terminal to persist / restore instance settings #766 - Restore the layout, position of windows
- This is partially implemented in Persist window layout on window close #10972
- Persist window layout cont. save multiple windows #11083 handles this for multiple windows.
Restore previously closed session's state (Buffer contents) #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.
Feature Request - Restore closed tab #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 Add support for tab tearoff and tab merge #1256 and Scenario: Windows Terminal 2.0 Process Model Improvements #5000 to sort themselves out before starting this one.
Move the commandline args to their own project #8841 and Add startupActions to SUI #8812 need to merge, so we can properly reflect all these options in the SUI.
Add a "Quit" action #11081
Preserve WT_SESSION across restarts #6362

Settings UI Mockup (programmer art warning)

2.0 Bugs

these are all presuming that #10972 merges basically as is

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"
		}
	]
}

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 8ffd314

Window names need to be persisted as well.

Was added to 11083 in a93d3b1
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.

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!

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.

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.

Try to persist the Pane's working directory if we know what it is. (#…

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.

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

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.

Change the `ControlCore` layer to own a copy of its settings (#11619)

Persist Runtime TabTitle and Maximize/Focus/Fullscreen states (#12073)

Add restore recently closed panes (#11471)

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 :).

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.

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 ☺️

Remove the need for TerminalPage to know the number of open windows

Navigation Menu

Repository navigation

megathread: Window State Persistence #9800

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

2.0 Bugs

2 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

megathread: Window State Persistence #9800

Description

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

2.0 Bugs

Activity

Rosefield commented on Sep 1, 2021

Rosefield commented on Sep 3, 2021

zadjii-msft commented on Sep 7, 2021

Rosefield commented on Sep 20, 2021

zadjii-msft commented on Sep 20, 2021

2 remaining items

ykoehler commented on Oct 15, 2021

zadjii-msft commented on Nov 23, 2021

Rosefield commented on Feb 6, 2022

zadjii-msft commented on Feb 7, 2022

zadjii-msft commented on Feb 7, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions