starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

New instance behavior doesn't work as expected with multiple monitors #18595

New Issue
Open
opened 2026-01-31 06:18:43 +00:00 by claunia · 10 comments
claunia commented 2026-01-31 06:18:43 +00:00
Owner
Copy Link

Originally created by @EvilVir on GitHub (Oct 3, 2022).

Windows Terminal version

1.15.2713.0

Windows build number

10.0.22621.0

Other Software

No response

Steps to reproduce

  • You need at least 2 monitors connected.
  • Set "New instance behavior" to "Attach to most recently used window on this desktop".
  • Open Terminal window and move it to other monitor.
  • Open another Terminal

Expected Behavior

Since first Terminal window is on different monitor, the second one should open new window.

Actual Behavior

Second terminal is opened as a tab in the window moved to second monitor.

Originally created by @EvilVir on GitHub (Oct 3, 2022). ### Windows Terminal version 1.15.2713.0 ### Windows build number 10.0.22621.0 ### Other Software _No response_ ### Steps to reproduce * You need at least 2 monitors connected. * Set "New instance behavior" to "Attach to most recently used window on this desktop". * Open Terminal window and move it to other monitor. * Open another Terminal ### Expected Behavior Since first Terminal window is on different monitor, the second one should open new window. ### Actual Behavior Second terminal is opened as a tab in the window moved to second monitor.
claunia added the Issue-FeatureProduct-TerminalArea-Windowing labels 2026-01-31 06:18:44 +00:00
claunia commented 2026-01-31 06:18:45 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 3, 2022):

Monitor != desktop. Each "virtual desktop" is comprised of all the monitors that are available. I don't believe we have a setting for "most recently used window, on this desktop, on this monitor".

@zadjii-msft commented on GitHub (Oct 3, 2022): Monitor != desktop. Each "virtual desktop" is comprised of all the monitors that are available. I don't believe we have a setting for "most recently used window, on this desktop, on this monitor".
claunia commented 2026-01-31 06:18:45 +00:00
Author
Owner
Copy Link

@EvilVir commented on GitHub (Oct 3, 2022):

Hm, I think multiple monitors are more used than virtual desktops TBH, maybe it would be good thing to then implement this feature?

@EvilVir commented on GitHub (Oct 3, 2022): Hm, I think multiple monitors are more used than virtual desktops TBH, maybe it would be good thing to then implement this feature?
claunia commented 2026-01-31 06:18:45 +00:00
Author
Owner
Copy Link

@carlos-zamora commented on GitHub (Oct 5, 2022):

Added this to the spec tracker just in case. We should update the existing spec for this new "new instance behavior" value just in case.

@carlos-zamora commented on GitHub (Oct 5, 2022): Added this to the spec tracker just in case. We should update the existing spec for this new "new instance behavior" value just in case.
claunia commented 2026-01-31 06:18:46 +00:00
Author
Owner
Copy Link

@marbaa commented on GitHub (Oct 13, 2022):

On multi-monitor setup every multiinstance software should detect on which monitor it is currently running. If I open terminal on primary monitor, then move it to the second monitor, hit Ctrl + Shift + N, the instance during launching must detect on which monitor is and open on secondary monitor, where the curosr, focus whatever is. But seems that developers generaly ignores this.

I believe the cases where somebody is working on secondary monitor and needs to open new instane on primary monitor are drasticaly less than cases where new instance is wanted to have opened on secondary monitor where the guy is working currently.

@marbaa commented on GitHub (Oct 13, 2022): On multi-monitor setup every multiinstance software should detect on which monitor it is currently running. If I open terminal on primary monitor, then move it to the second monitor, hit Ctrl + Shift + N, the instance during launching must detect on which monitor is and open on secondary monitor, where the curosr, focus whatever is. But seems that developers generaly ignores this. I believe the cases where somebody is working on secondary monitor and needs to open new instane on primary monitor are drasticaly less than cases where new instance is wanted to have opened on secondary monitor where the guy is working currently.
claunia commented 2026-01-31 06:18:46 +00:00
Author
Owner
Copy Link

@EvilVir commented on GitHub (Oct 13, 2022):

Well I don’t have any telemetry to back me up but based on my workflow I see a lack of this feature problematic. It would be less annoying if other feature (moving tabs between windows) worked.

In general if I move window to secondary monitor it means that it has some session I’m not currently focusing on. Usually something long running. Then if I have my focus and mouse on primary monitor I would expect new window to pop up on it because I want to start new session/batch of work. Not once I canceled job that was running in terminal for hours, by mistake, because I closed the whole terminal window after doing some quick stuff in other tab. I was sure I’m on different window than my long job is, as I remembered I put that on the secondary screen.

@EvilVir commented on GitHub (Oct 13, 2022): Well I don’t have any telemetry to back me up but based on my workflow I see a lack of this feature problematic. It would be less annoying if other feature (moving tabs between windows) worked. In general if I move window to secondary monitor it means that it has some session I’m not currently focusing on. Usually something long running. Then if I have my focus and mouse on primary monitor I would expect new window to pop up on it because I want to start new session/batch of work. Not once I canceled job that was running in terminal for hours, by mistake, because I closed the whole terminal window after doing some quick stuff in other tab. I was sure I’m on different window than my long job is, as I remembered I put that on the secondary screen.
claunia commented 2026-01-31 06:18:46 +00:00
Author
Owner
Copy Link

@marbaa commented on GitHub (Oct 17, 2022):

Yeah, the lack of ability to drag tab to new window, or to other window seems to be hard problem for software made by Microsoft.

In my case as a Linux infrastructure guy, I always have several ssh connections opened. Either on primary or secondary, almost always on both. Often I have some docu opened in front of me, and active ssh session on secondary monitor. Not fullscreen, because why would I need. Then I want to open new window, because I want temporary test something what I read in docu, and bam. New window is on primary monitor, then need to grab mouse and move it back.

Same is with browsers. If I work on secondary monitor in iDRAC, and I open Virtual Console, for some stupid reason, the new tab is opened on primary monitor, which is really silly.

@marbaa commented on GitHub (Oct 17, 2022): Yeah, the lack of ability to drag tab to new window, or to other window seems to be hard problem for software made by Microsoft. In my case as a Linux infrastructure guy, I always have several ssh connections opened. Either on primary or secondary, almost always on both. Often I have some docu opened in front of me, and active ssh session on secondary monitor. Not fullscreen, because why would I need. Then I want to open new window, because I want temporary test something what I read in docu, and bam. New window is on primary monitor, then need to grab mouse and move it back. Same is with browsers. If I work on secondary monitor in iDRAC, and I open Virtual Console, for some stupid reason, the new tab is opened on primary monitor, which is really silly.
claunia commented 2026-01-31 06:18:46 +00:00
Author
Owner
Copy Link

@pacanukeha commented on GitHub (Feb 13, 2023):

In general if I move window to secondary monitor it means that it has some session I’m not currently focusing on.

This isn't my experience. I generally work on laptops with multiple external monitors. the laptop stays as primary and off to one side because windows draws the system tray and notifications on only the primary monitor and I rarely want them on any of my "work" screens.

@pacanukeha commented on GitHub (Feb 13, 2023): > In general if I move window to secondary monitor it means that it has some session I’m not currently focusing on. This isn't my experience. I generally work on laptops with multiple external monitors. the laptop stays as primary and off to one side because windows draws the system tray and notifications on only the primary monitor and I rarely want them on any of my "work" screens.
claunia commented 2026-01-31 06:18:47 +00:00
Author
Owner
Copy Link

@EvilVir commented on GitHub (Feb 13, 2023):

@pacanukeha I don't think that changes anything. By "secondary" I meant monitor you don't focus on (eg. your "non-work" screen), not which number it has assigned in Windows Display Settings nor where notifications pops up.

@EvilVir commented on GitHub (Feb 13, 2023): @pacanukeha I don't think that changes anything. By "secondary" I meant monitor you don't focus on (eg. your "non-work" screen), not which number it has assigned in Windows Display Settings nor where notifications pops up.
claunia commented 2026-01-31 06:18:47 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Feb 13, 2023):

This may not be something we can implement to a particularly satisfactory degree.

When an application is started1 , it doesn't do so with a monitor in mind. The machinery that starts up a new process is display-agnostic, and there isn't really an "active" monitor that we can make assumptions about. A couple examples of questions we'd need to answer in a proposal:

  • We could decide that the active monitor is the one that contains the foreground window. OK!
    • When you run WT from the run dialog, the Run dialog is the foreground window. It always shows up on the primary display... is that where we should start looking for Terminal windows?
    • If you start a process in one Terminal window that would spawn another tab/another window, should it stick to the window it was started from? What if it's not started while Terminal's active--should it start in a Terminal window on the monitor you're looking at?

  1. Regardless of who/what is doing it and when, the New Instance Behavior only triggers in response to some application being launched--whether it's wt directly or cmd causing it to launch indirectly. ↩︎

@DHowett commented on GitHub (Feb 13, 2023): This may not be something we _can_ implement to a particularly satisfactory degree. When an application is started[^1], it doesn't do so with a monitor in mind. The machinery that starts up a new process is display-agnostic, and there isn't really an "active" monitor that we can make assumptions about. A couple examples of questions we'd need to answer in a proposal: - We could decide that the active monitor is the one that contains the foreground window. _OK!_ - When you run WT from the run dialog, the Run dialog is the foreground window. It always shows up on the primary display... is that where we should start looking for Terminal windows? - If you start a process in one Terminal window that would spawn another tab/another window, should it stick to the window it was started _from_? What if it's not started while Terminal's active--should it start in a Terminal window on the monitor you're looking at? [^1]: Regardless of who/what is doing it and when, the New Instance Behavior only triggers in response to _some application_ being launched--whether it's `wt` directly or `cmd` causing it to launch indirectly.
claunia commented 2026-01-31 06:18:47 +00:00
Author
Owner
Copy Link

@marbaa commented on GitHub (Feb 13, 2023):

@DHowett IMO, answers to yours questions are pretty simple. Active window or cursor location or both at the same time should be the deciding point. But most logicaly the window which has focus should be deciding point. So.

  • When you run WT from RUN dialog, your current WT loses focus and new WT instance is spawned on primary monitor. That's correct, because focus is inside RUN dialog which is on primary monitor and, we have more ways to spawn new WT instance.

  • First question of second point - if you have focus in WT instance, and spawn new instance with CTRL + SHIFT + N, then expected behaviour is to spawn new WT on this monitor where current WT from which was new instance spawned. That means if it is on monitor one, then spawn it on monitor one. If it is running on monitor two, then new instance is spawned on monitor two.

  • Second question of second point - if current WT doesn't have focus, then there are only one and a half ways how to spawn new WT instance. Either from RUN dialog (that is clear now, see my first question answer) - or by pressing global hotkey WIN + SHIFT + number, but that is only in case that WT is pinned to taskbar. In that case, I would spawn new WT based on cursor location, so you don't need to count with this
    image
    Or by executing shortcut on desktop, in that case cursor location is simple deciding point, where spawn new WT instance.

@marbaa commented on GitHub (Feb 13, 2023): @DHowett IMO, answers to yours questions are pretty simple. Active window or cursor location or both at the same time should be the deciding point. But most logicaly the window which has focus should be deciding point. So. - When you run WT from RUN dialog, your current WT loses focus and new WT instance is spawned on primary monitor. That's correct, because focus is inside RUN dialog which is on primary monitor and, we have more ways to spawn new WT instance. - First question of second point - if you have focus in WT instance, and spawn new instance with CTRL + SHIFT + N, then expected behaviour is to spawn new WT on this monitor where current WT from which was new instance spawned. That means if it is on monitor one, then spawn it on monitor one. If it is running on monitor two, then new instance is spawned on monitor two. - Second question of second point - if current WT doesn't have focus, then there are only one and a half ways how to spawn new WT instance. Either from RUN dialog (that is clear now, see my first question answer) - or by pressing global hotkey WIN + SHIFT + number, but that is only in case that WT is pinned to taskbar. In that case, I would spawn new WT based on cursor location, so you don't need to count with this ![image](https://user-images.githubusercontent.com/40859847/218580504-2d7e8f69-91bc-432e-8d6b-57f1f9f021fd.png) Or by executing shortcut on desktop, in that case cursor location is simple deciding point, where spawn new WT instance.
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-Windowing Issue-Feature 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#18595
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?