Terminal startup location partially off Desktop

[csylvain]

Environment

Windows build number: [run `[Environment]::OSVersion` for powershell, or `ver` for cmd]
 10.0.18362.418
Windows Terminal version (if applicable):
 0.5.2762.0

Any other software?

Steps to reproduce

1. change "initialRows": 44 in Settings
2. change "defaultProfile": "{c6eaf9f4-32a7-5fdc-b5cf-066e8a4b1e40}" # ubuntu-18.04
3. Start -> Windows Terminal (Preview)

Expected behavior

entire Terminal with default profile on screen in its entirety is expected to be seen on Desktop

Actual behavior

Terminal appears to open with 14 lines off the bottom of the Desktop (behind and below the Taskbar). there does not seem to be "initialXpos" nor "initialYpos" in Settings to manually place Terminal in its entirety on the Desktop.

[DHowett-MSFT]

Hey thanks! This is a /dupe of #1043

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

[csylvain]

notfixed by #2817
different than #1043 -- if i close Terminal in position where it is entirely on the Desktop, then start Terminal again and it's back to the partially off Desktop position again. i reported an issue because there does not seem to be a workaround.

[DHowett-MSFT]

Incoming notes from #4681

Environment

Windows build number: 1903  Build 18362.657
Windows Terminal version (if applicable):  0.9.433.0

Any other software?

Steps to reproduce

1. Change the settings to have a large number of lines, but a number that will fit on your screen, but only by an inch or so.
2. Start Windows Terminal repeatedly, noting that,eventually, the bottom of the terminal window goes beyond the bottom of the screen. This may take several attempts before the 'default' start position is too close to the bottom of the screen.

Expected behavior

I expect (hope?) that modern programs either save/restore the previous window size & position OR that the programs ensure that their entire window is visible when started.

If the window is larger than the screen, I would expect either

• The top,left corner of the window to be at the top,left corner of the monitor
• Optionally, the window size adjusted to fit on the screen automatically or, in the case of a terminal window, perhaps the font size adjusted downward until the window fits on the screen.

Actual behavior

I had my terminal configured to a rather large font and 50 lines at startup. This morning when I started it, the bottom 1/4 to 1/3 (I'm guessing) of the terminal window was below the bottom of the screen. There was more than enough space on screen ABOVE the terminal and it was easy enough to move, but the code should not require me to move it in order to see the whole window when it first loads!

[dynahcatq]

I'm looking at this issue and I have some questions:

1. the programs ensure that their entire window is visible when started <- Can a user overwrite this behavior? Suppose they set the initialPosition in settings.json and half of the window is not visible, should we adjust the window's position?
2. If the window is too large to fit the screen, should we adjust window to fit the screen or reposition it to top-left corner?

[csylvain]

related to this are the window coordinates acquired when using multiple monitors. it's an infamous bug for a window to retain entirely off-screen coordinates when the stretched mega-monitor area shrinks when one or more monitors are disconnected.

[dynahcatq]

@csylvain So when a user specified an initialPosition that would cause the off-screen coordinates, we should correct all 4 coordinates to be within the screen right?

[csylvain]

there's no nice way to retrieve a window with completely off-screen coordinates. yes, when faced with coordinates which cannot in any way been seen because other monitors have vanished, it would be A Good Thing(tm) to reset the window's coordinates where it can be seen again. it is the point, after all, of creating a window, yes? to be seen (somewhere, somehow) ? (disappearing multi-monitors having been treated as One Big Monitor is obviously a worst-case situation)

[dynahcatq]

@DHowett-MSFT Hi, after taking a look at the issue I would like to propose a fix to the issue.

1. Check the window's 4 corners (top-left, bottom-left, top-right, bottom-right) to determine if it is out of screen and reset top-left to (monitorInfo.rcWork.top, monitorInfo.rcWork.left), which normally will be (0, 0).
2. If the window's size should fit in the monitor, check if partial window is behind the taskbar (reset top-left coord if taskbar overlap).

What do you think?

[DHowett-MSFT]

We'd definitely be willing to accept contributions that improve the art here 😄

[DHowett-MSFT]

(We need to consider, of course, how folks may have multi-monitor layouts and the application could be at a negative position with regards to the primary display.)

[dynahcatq]

For the first part, I'm planning to use EnumDisplayMonitors to deal with multi-monitor layouts. So if four corners are in different monitor, it will be treated as visible and will not trigger the reset.

[csylvain]

a fair number of "regular folk" run a pair of monitors these days. the invisible off-screen window is infamous in ham radio circles. i'd expect document processors have encountered it, too. yes, the coords could be far positive or negative relative to the remaining monitors. dynahcatq's description of how to return to coordinate sanity with remaining monitor(s) sounds perfect.

[Poopooracoocoo]

I use Sizer from BrianApps and it bugs me that Terminal doesn't remember the size and position. Most apps work great with Sizer. I also cannot right click on the title bar buttons to show Sizer's context menu. Speaking of the title bar, the elements in it don't "fade" when it's inactive. I'm pretty sure Terminal has a custom title bar.

[Poopooracoocoo]

@DHowett hey are there any updates on the priority of this?

[zadjii-msft]

two thoughts looking at random other code:

• We could absolutely pass the expected width&height of the default settings for the window into the call to CreateWindow. That would at least put the default window at a sensible place.
• We probably could adjust the window position in AppHost::_initialResizeAndRepositionWindow. At that point, the settings would be loaded. That method is gonna try and calculate the starting pos & size. So it can know both. That's a place where we could make some adjustments to the initial position if
  • it was unset in the settings
  • the current dimensions would take it outside the bounds of the monitor

I dunno if we could be more preemptive and pass _windowLogic.GetInitialPosition et al. into the call to CreateWindow. I don't think so.

[64-bitman]

Any update on this?