Opening a new terminal window does not restore the previous window's size and position on the screen

[Poopooracoocoo]

Windows Terminal version

1.13.10395.0

Windows build number

10.0.19044

Other Software

No response

Steps to reproduce

1. Open Terminal
2. Resize and reposition window
3. Close window
4. Open Terminal again

Expected Behavior

Terminal would open the window in the same position and size

Actual Behavior

The position and size are reset.

Note: I am not referring to session restore on start-up like you'd find in a web browser that can be enabled optionally. I'm referring to regular behaviour that people expect on desktop operating systems. And in particular, this makes it easier to use on smaller screens such as laptops.

[Rosefield]

Do you have window layout saving enabled? In Settings -> Startup -> "When Terminal starts" select the "Open windows from a previous session" option.

https://docs.microsoft.com/en-us/windows/terminal/customize-settings/startup#behavior-when-starting-a-new-terminal-session

[Poopooracoocoo]

Do you have window layout saving enabled? In Settings -> Startup -> "When Terminal starts" select the "Open windows from a previous session" option.

I don't want that, nor should I need that enabled to have this.

Edit: I even explicitly mentioned that option in my issue. No edits.

[zadjii-msft]

Alright so this is a new feature request - a setting to use the initialPosition, initialSize in state.json instead of the ones in the settings file. I suppose that could be a checkbox within the Launch Size expander. Ah, but then we've got the trick that we'd want one checkbox for "use previous position" and another for "use previous size". (admittedly, initialPosition isn't in the SUI yet, #9075). Then there's also the complicating factor that enabling "Open windows from a previous session" would spooky-action-at-a-distance check and disable those boxes.

So then it makes more sense to put this as another radio option in "When Terminal starts...". Or like, a checkbox under the "Open a tab with the default profile", that only revealsenables itself when that radio button is selected? (hiding itself would be terrible discoverability)

[Poopooracoocoo]

An option doesn't really make sense to me. I don't really want anything complicated. I just want the default windowing behaviour I've come to expect from other apps. 🤷

[zadjii-msft]

We already have some other settings to control where the window is positioned and how big it is, so already we're off the rails of "other apps". I'm of the strong opinion that user preference is king - I'd love to give everyone as many knobs to control the Terminal as possible, to make it work exactly like they'd like.

[Poopooracoocoo]

Good defaults are always nice tho :)

[SteveALee]

I agree, it should just work its standard windows behaviour. Should respect the monitor it was on as well. Let people override if required but please follow principle of least surprises.

[DHowett]

Discussion outcome: This probably needs a miniature spec (AKA: we agree on it in the issue, and check in a quick markdown document about it) as the team couldn't come to consensus on whether this is a firstWindowPreference or a launchPosition, and whether this is part of or not a part of the session restoration code.

[SteveALee]

Thanks for bringing the outcome here!

[Stanzilla]

Hah just came here to report this, I was thinking of two suggestions:

1. Option to always spawn at a set of coordinates OR at the center of the screen
2. Remember position properly

[zadjii-msft]

FWIW:

Option to always spawn at a set of coordinates OR at the center of the screen are already settings.

Unifying those two with bullet point 2 is the one that this issue is tracking - finding a good way of exposing that setting to the user both as a UI and in json is the hard part.

[Stanzilla]

FWIW:

Option to always spawn at a set of coordinates OR at the center of the screen are already settings.

Unifying those two with bullet point 2 is the one that this issue is tracking - finding a good way of exposing that setting to the user both as a UI and in json is the hard part.

Oh my bad, sorry. I didn't see it in the UI options.

[zadjii-msft]

Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button?

That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️

As it stands, this issue remains at:

Discussion outcome: This probably needs a miniature spec (AKA: we agree on it in the issue, and check in a quick markdown document about it) as the team couldn't come to consensus on whether this is a firstWindowPreference or a launchPosition, and whether this is part of or not a part of the session restoration code.

If someone wants to sort out how exactly this should be implemented, we'd be more than happy to review a writeup ☺️

---

Some notes, march 2023:

• On my branch
• You delete tabLayout entirely (is null) -> right size & pos, but explodes
• you set tabLayout to [] -> Right size & pos, and uses the default profile

around 434abc2 (during #14825), this was actually almost trivially easy. We made the logic concerning the number of tabs persisted a bit more strict, but honestly, I think we could undo that easily. Commit 1b59eb9 was the one to enforce the "we must have tabs" thing

[lhecker]

If someone wants to sort out how exactly this should be implemented, we'd be more than happy to review a writeup ☺️

FWIW, and when it comes to the implementation specifically, I believe this should use the GetWindowPlacement and SetWindowPlacement APIs. Those have been in use by other HWND applications for this purpose since forever.

[Gavitron]

Is this still an open bug? I'm unable to get wt to open on any monitor but the primary, without hard-coding an absolute position.

Windows Version 10.0.19045 Build 19045
Windows Terminal Version 1.17.11461.0

settings.json:

    "initialPosition": ",",
    "launchMode": "default",
    "firstWindowPreference": "defaultProfile",
    "centerOnLaunch": false,

Steps to reproduce:

1. Start windows terminal from shortcut on desktop of monitor two.
   ( Shortcut points to %LOCALAPPDATA%\Microsoft\WindowsApps\wt.exe)
2. terminal opens on monitor one.
3. drag window to monitor two.
4. Close window via any method. (tested all of: window-close widget, tab-close widget, alt+F4. typing "exit" in terminal)
5. Start windows terminal from shortcut on monitor two.

Expected behaviour:

terminal opens on monitor two, with previous state

Observed behaviour:

terminal opens on monitor one in a "default" state. (though not one explicitly set)

note: as alluded to above, I worked around this bug by hard-coding a window position, but now if I start a second terminal instance, it perfectly overlaps the first, instead of being offset by ~50px as usually happens when letting Windows decide.