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

Using Windows+Shift+(arrow key) to move Terminal between monitors with different scaling ratios causes incorrect resize of the window #8609

New Issue
Open
opened 2026-01-31 01:33:40 +00:00 by claunia · 13 comments
claunia commented 2026-01-31 01:33:40 +00:00
Owner
Copy Link

Originally created by @AaronKelley on GitHub (May 26, 2020).

Environment

Windows build number: 10.0.18363.836
Windows Terminal version (if applicable): 1.0.1401.0

Steps to reproduce

Two monitors in the environment: One is 4K resolution, scaling ratio 200%; the other is 1080p resolution, scaling ratio 100%
The 4K monitor is the default monitor.

Open Windows Terminal. It opens on the 4K monitor.
Use "Windows+Shift+right arrow" to move it to the 1080p monitor.

Expected behavior

Windows Terminal should show up on the 1080p monitor with the same number of rows and columns as it had when it was on the 4K monitor. (This is what happens if you drag it over.)

Actual behavior

Windows Terminal has been sized down and has half of the rows and columns that it had before the move.

Originally created by @AaronKelley on GitHub (May 26, 2020). # Environment ```none Windows build number: 10.0.18363.836 Windows Terminal version (if applicable): 1.0.1401.0 ``` # Steps to reproduce Two monitors in the environment: One is 4K resolution, scaling ratio 200%; the other is 1080p resolution, scaling ratio 100% The 4K monitor is the default monitor. Open Windows Terminal. It opens on the 4K monitor. Use "Windows+Shift+right arrow" to move it to the 1080p monitor. # Expected behavior Windows Terminal should show up on the 1080p monitor with the same number of rows and columns as it had when it was on the 4K monitor. (This is what happens if you *drag* it over.) # Actual behavior Windows Terminal has been sized down and has half of the rows and columns that it had before the move.
claunia commented 2026-01-31 01:33:41 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (May 28, 2020):

As far as I understand, the Win+Shift+Arrow shortcuts prefer window snapping. When I move my terminal across my two (different scaling factor) screens, it snaps to the right of monitor 1 (resizing it), then the left of monitor 2 (resizing it because monitor 2 is a different size and scale), then back to a floating window. Is that incorrect? Should we not snap?

@DHowett commented on GitHub (May 28, 2020): As far as I understand, the <kbd>Win+Shift+Arrow</kbd> shortcuts prefer window snapping. When I move my terminal across my two (different scaling factor) screens, it snaps to the right of monitor 1 (resizing it), then the left of monitor 2 (resizing it because monitor 2 is a different size and scale), then back to a floating window. Is that incorrect? Should we not snap?
claunia commented 2026-01-31 01:33:41 +00:00
Author
Owner
Copy Link

@AaronKelley commented on GitHub (May 28, 2020):

Win+Arrow does snapping. Win+Shift+Arrow should move the window between monitors without snapping. That is what I am referring to here.

@AaronKelley commented on GitHub (May 28, 2020): Win+Arrow does snapping. Win+Shift+Arrow should move the window between monitors without snapping. That is what I am referring to here.
claunia commented 2026-01-31 01:33:42 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (May 28, 2020):

Whoa, today I learned!

@DHowett commented on GitHub (May 28, 2020): Whoa, today I learned!
claunia commented 2026-01-31 01:33:42 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 28, 2020):

So this will repro by just dragging the window across a DPI boundary as well.

I don't know how to fix this one. As of the differential drawing patch, we recalculate a new font size for the new DPI. However, fonts don't necessarily scale linearly with the DPI, and neither does the rest of the UI. So when we move to another monitor, the window gets scaled to a new size, but the number of characters that fit into that new size might be different.

I think conhost dealt with this proactively - when conhost gets told it's about to move to a new DPI, it's able to say "make my window X by Y at that DPI". However, I'm not sure we in the Terminal could do that. We could probably calcualate how bit the TermControls would need to be, but pane borders, tab strips, other UI elements, those I don't know about.

I'll stick this on the backlog as a head scratcher. Maybe we could use something like the pane snapping code to figure it out, but it wouldn't be easy.

@zadjii-msft commented on GitHub (May 28, 2020): So this will repro by just dragging the window across a DPI boundary as well. I don't know how to fix this one. As of the differential drawing patch, we recalculate a new font size for the new DPI. However, fonts don't necessarily scale linearly with the DPI, and neither does the rest of the UI. So when we move to another monitor, the window gets scaled to a new size, but the number of characters that fit into that new size _might be different_. I think conhost dealt with this proactively - when conhost gets told it's about to move to a new DPI, it's able to say "make my window X by Y at that DPI". However, I'm not sure we in the Terminal could do that. We could _probably_ calcualate how bit the TermControls would need to be, but pane borders, tab strips, other UI elements, those I don't know about. I'll stick this on the backlog as a head scratcher. Maybe we could use something like the pane snapping code to figure it out, but it wouldn't be easy.
claunia commented 2026-01-31 01:33:42 +00:00
Author
Owner
Copy Link

@mparry commented on GitHub (Feb 8, 2022):

So this will repro by just dragging the window across a DPI boundary as well.

I don't see this, and I think nor did the OP. If, with a setup matching OP's, I drag a window between monitors then, once dropped, it will retain its pre-move visual size, as desired. If I use Win+Shift+L/R Arrow then it halves in size visually. Has behaviour changed, or did you mean something different?

Besides curiosity, I mainly ask about this in case it helps solve the issue.

(I do see size weirdness when dragging and the window still straddles the boundaries, but that's because presumably there's nothing sensible to do at that point, and that's certainly not unique to Terminal.)

@mparry commented on GitHub (Feb 8, 2022): > So this will repro by just dragging the window across a DPI boundary as well. I don't see this, and I think nor did the OP. If, with a setup matching OP's, I drag a window between monitors then, once dropped, it will retain its pre-move visual size, as desired. If I use Win+Shift+L/R Arrow then it halves in size visually. Has behaviour changed, or did you mean something different? Besides curiosity, I mainly ask about this in case it helps solve the issue. (I do see size weirdness when dragging and the window still _straddles_ the boundaries, but that's because presumably there's nothing sensible to do at that point, and that's certainly not unique to Terminal.)
claunia commented 2026-01-31 01:33:42 +00:00
Author
Owner
Copy Link

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

If I use Win+Shift+L/R Arrow then it halves in size visually.

Uh what now? I'm definitely not seeing that. Are you seeing something like #11317?

@zadjii-msft commented on GitHub (Feb 8, 2022): > If I use Win+Shift+L/R Arrow then it halves in size visually. Uh what now? I'm definitely not seeing that. Are you seeing something like #11317?
claunia commented 2026-01-31 01:33:42 +00:00
Author
Owner
Copy Link

@AaronKelley commented on GitHub (Feb 8, 2022):

OP here. I'm not able to reproduce this anymore.

@AaronKelley commented on GitHub (Feb 8, 2022): OP here. I'm not able to reproduce this anymore.
claunia commented 2026-01-31 01:33:42 +00:00
Author
Owner
Copy Link

@mparry commented on GitHub (Feb 8, 2022):

Uh what now? I'm definitely not seeing that. Are you seeing something like #11317?

I don't think so - I think I'm seeing exactly what was described in the OP (despite them no longer seeing it!)

I can probably provide screenshots if that would help?

I am running Terminal 1.13.220202006, incidentally.

@mparry commented on GitHub (Feb 8, 2022): > Uh what now? I'm definitely not seeing that. Are you seeing something like #11317? I don't think so - I think I'm seeing exactly what was described in the OP (despite them no longer seeing it!) I can probably provide screenshots if that would help? I am running Terminal 1.13.220202006, incidentally.
claunia commented 2026-01-31 01:33:43 +00:00
Author
Owner
Copy Link

@mparry commented on GitHub (Feb 8, 2022):

It may be related to having initialCols, initialRows and/or initialPosition specified in the config.

My Terminal opens on the 1080p 100% scale monitor by default (as dictated by those values). If I hit Win+Shift+L Arrow to move it to the 4k 200% scale monitor then it stays the same size. If I hit Win+Shift+R Arrow to move it back, it halves in size.

I can't reproduce this if I remove those config settings. Perhaps this is therefore a separate problem and I should open a fresh issue?

@mparry commented on GitHub (Feb 8, 2022): It may be related to having `initialCols`, `initialRows` and/or `initialPosition` specified in the config. My Terminal opens on the 1080p 100% scale monitor by default (as dictated by those values). If I hit Win+Shift+L Arrow to move it to the 4k 200% scale monitor then it stays the same size. If I hit Win+Shift+R Arrow to move it back, it halves in size. I can't reproduce this if I remove those config settings. Perhaps this is therefore a separate problem and I should open a fresh issue?
claunia commented 2026-01-31 01:33:43 +00:00
Author
Owner
Copy Link

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

Screenshots or a recording (try screenToGif) would be helpful for sure. A picture says 1000 words 😉

I can't reproduce this if I remove those config settings.

That really doesn't make any sense to me - those settings should only be used when the window is loaded. initialCols & initialRows have default values that (when omitted from settings.json) they fall back to. initialPosition is a little different though, that might be the singular setting that triggers this one.

@zadjii-msft commented on GitHub (Feb 8, 2022): Screenshots or a recording (try screenToGif) would be helpful for sure. A picture says 1000 words 😉 > I can't reproduce this if I remove those config settings. That really doesn't make any sense to me - those settings should only be used when the window is loaded. `initialCols` & `initialRows` have default values that (when omitted from settings.json) they fall back to. `initialPosition` is a little different though, that might be the singular setting that triggers this one.
claunia commented 2026-01-31 01:33:43 +00:00
Author
Owner
Copy Link

@wenbozzz commented on GitHub (Feb 11, 2022):

I'm still able to reproduce this, here's the screen recoding:
https://user-images.githubusercontent.com/1872200/153527209-999f44eb-0dff-42a2-9e04-e2c57ab47cc3.mp4

Windows terminal version is 1.11.3471.0, installed from Microsoft store

My monitor setup is like screenshot below:
Screenshot 2022-02-11 100605
Screen 1 is the Surface Pro touch screen: 2736x1824 @ 175% scale
Screen 2 is my external monitor: 3440 x 1440 @ 100% scale

edit: also able to reproduce when moving terminal window with win + shift + arrow keys (tho it's less likely to reproduce comparing to drag the window with mouse)
https://user-images.githubusercontent.com/1872200/153528098-e2ee68c4-2429-4cf2-bb9f-74a48b93201c.mp4

@wenbozzz commented on GitHub (Feb 11, 2022): I'm still able to reproduce this, here's the screen recoding: https://user-images.githubusercontent.com/1872200/153527209-999f44eb-0dff-42a2-9e04-e2c57ab47cc3.mp4 Windows terminal version is 1.11.3471.0, installed from Microsoft store My monitor setup is like screenshot below: ![Screenshot 2022-02-11 100605](https://user-images.githubusercontent.com/1872200/153527267-88be14fb-e57b-4cef-a1df-cb4818bb2929.png) Screen 1 is the Surface Pro touch screen: 2736x1824 @ 175% scale Screen 2 is my external monitor: 3440 x 1440 @ 100% scale edit: also able to reproduce when moving terminal window with win + shift + arrow keys (tho it's less likely to reproduce comparing to drag the window with mouse) https://user-images.githubusercontent.com/1872200/153528098-e2ee68c4-2429-4cf2-bb9f-74a48b93201c.mp4
claunia commented 2026-01-31 01:33:44 +00:00
Author
Owner
Copy Link

@mparry commented on GitHub (Feb 11, 2022):

Here are some screenshots illustrating what I see:

1_1080p
2_4k
3_1080p

So as I described previously, this is:

  1. Starts on a 1080p monitor, in its normal position
  2. After pressing Win+Shift+L Arrow it's now on my 4k monitor, still the expected size
  3. After pressing Win+Shift+R Arrow to send it back to the original 1080p monitor, it's now shrunk!

With regards to the initialCols, initialRows and/or initialPosition settings in config, I think it's just that any size other than the default will cause this to happen, whereas it seems not to with a default sized window - i.e. I can still reproduce it if I remove those settings but then resize the window by hand.

@mparry commented on GitHub (Feb 11, 2022): Here are some screenshots illustrating what I see: ![1_1080p](https://user-images.githubusercontent.com/20336381/153571106-ef38d4de-d735-4d4c-8f07-64c5d18961e9.png) ![2_4k](https://user-images.githubusercontent.com/20336381/153571090-fb868a2e-485d-4584-b23e-ac66859d79e6.png) ![3_1080p](https://user-images.githubusercontent.com/20336381/153571103-4ce872b2-413d-4d11-aa41-4e9c15de9977.png) So as I described previously, this is: 1) Starts on a 1080p monitor, in its normal position 2) After pressing Win+Shift+L Arrow it's now on my 4k monitor, still the expected size 3) After pressing Win+Shift+R Arrow to send it back to the original 1080p monitor, it's now shrunk! With regards to the `initialCols`, `initialRows` and/or `initialPosition` settings in config, I think it's just that any size other than the default will cause this to happen, whereas it seems not to with a default sized window - i.e. I can still reproduce it if I remove those settings but then resize the window by hand.
claunia commented 2026-01-31 01:33:44 +00:00
Author
Owner
Copy Link

@wenbozzz commented on GitHub (Feb 11, 2022):

oh, sorry my bad.. the stuffs I posted is related to another issue, not this one.

@wenbozzz commented on GitHub (Feb 11, 2022): oh, sorry my bad.. the stuffs I posted is related to another issue, not this one.
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-UserInterface Help Wanted Issue-Bug Priority-3 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#8609
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?