Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

START /MIN WT? #9053

Closed
vefatica opened this issue Feb 5, 2021 · 5 comments · Fixed by #12979 or #13838
Closed

START /MIN WT? #9053

vefatica opened this issue Feb 5, 2021 · 5 comments · Fixed by #12979 or #13838
Labels
Area-UserInterface Issues pertaining to the user interface of the Console or Terminal Help Wanted We encourage anyone to jump in on these. In-PR This issue has a related PR Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-2 A description (P2) Product-Terminal The new Windows Terminal.

Comments

@vefatica
Copy link

vefatica commented Feb 5, 2021

Environment

Microsoft Windows 10 Pro for Workstations
10.0.19042.746 (2009, 20H2)
WindowsTerminalPreview_1.6.10272.0_x64

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

Any other software?

Steps to reproduce

In CMD.EXE, issue START /MIN WT

Expected behavior

WT starts minimized and can be restored.

Actual behavior

WT starts minimized and can't be restored. The taskbar icon is rather lame.

I couldn't get good pics of the taskbar icon's popup thumbnails because they close when I activate the screen clipper.

@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Feb 5, 2021
@KalleOlaviNiemitalo
Copy link

Related issues, although not duplicates:

@zadjii-msft
Copy link
Member

Yea, this is definitely unique compared to the other two. Repros easy enough. Real weird. I wonder if the OS is unhappy about us trying to set a window position when starting minimized is requested. Hard to know for sure, user32 is a mystery ¯\_(ツ)_/¯

@zadjii-msft zadjii-msft added Area-UserInterface Issues pertaining to the user interface of the Console or Terminal Help Wanted We encourage anyone to jump in on these. Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-2 A description (P2) Product-Terminal The new Windows Terminal. labels Feb 8, 2021
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Feb 8, 2021
@zadjii-msft zadjii-msft added this to the Terminal v2.0 milestone Feb 8, 2021
@just1a-person
Copy link

Screenshots from Alt-Tab:

WT weirdness

@DHowett DHowett removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Feb 12, 2021
@zadjii-msft zadjii-msft modified the milestones: Terminal v2.0, Backlog Jan 4, 2022
zadjii-msft added a commit that referenced this issue Apr 27, 2022
@zadjii-msft
Copy link
Member

We accidentally found the fix for this in 75d3065, in #12979

@ghost ghost added the In-PR This issue has a related PR label Apr 27, 2022
@ghost ghost closed this as completed in #12979 May 6, 2022
ghost pushed a commit that referenced this issue May 6, 2022
…2979)

When we start up, our window is initially just a frame with a transparent content area. We're gonna do all this startup init on the UI thread, so the UI won't actually paint till it's all done. This results in a few frames where the frame is visible, before the page paints for the first time, before any tabs appears, etc. 

To mitigate this, we're gonna wait for the UI thread to finish everything it's gotta do for the initial init, and _then_ fire our Initialized event. By waiting for everything else to finish (`CoreDispatcherPriority::Low`), we let all the tabs and panes actually get created. In the window layer, we're gonna ~cloak~ just not show the window till this event is fired, so we don't actually see this frame until we're actually all ready to go. **This will result in the window seemingly not loading as fast**, but it will actually take exactly the same amount of time before it's usable. 

I also experimented with drawing a solid BG color before the initialization is finished. However, there are still a few frames after the frame is displayed before the XAML content first draws, so that didn't actually resolve any issues.

* [x] Closes #11561
* [x] Tested manually
* [x] I work here.
* [x] Accidentally also closes #9053. By switching the initial call from `ShowWindow(SW_SHOW)` to `ShowWindow(SW_SHOWDEFAULT)`, we actually obey the startup info now.
@ghost ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels May 6, 2022
carlos-zamora pushed a commit that referenced this issue May 6, 2022
…2979)

When we start up, our window is initially just a frame with a transparent content area. We're gonna do all this startup init on the UI thread, so the UI won't actually paint till it's all done. This results in a few frames where the frame is visible, before the page paints for the first time, before any tabs appears, etc.

To mitigate this, we're gonna wait for the UI thread to finish everything it's gotta do for the initial init, and _then_ fire our Initialized event. By waiting for everything else to finish (`CoreDispatcherPriority::Low`), we let all the tabs and panes actually get created. In the window layer, we're gonna ~cloak~ just not show the window till this event is fired, so we don't actually see this frame until we're actually all ready to go. **This will result in the window seemingly not loading as fast**, but it will actually take exactly the same amount of time before it's usable.

I also experimented with drawing a solid BG color before the initialization is finished. However, there are still a few frames after the frame is displayed before the XAML content first draws, so that didn't actually resolve any issues.

* [x] Closes #11561
* [x] Tested manually
* [x] I work here.
* [x] Accidentally also closes #9053. By switching the initial call from `ShowWindow(SW_SHOW)` to `ShowWindow(SW_SHOWDEFAULT)`, we actually obey the startup info now.

(cherry picked from commit 14098d7)
Service-Card-Id: 81599073
Service-Version: 1.14
@zadjii-msft
Copy link
Member

Whoops, we reverted this but never reopened it.

@ghost ghost added the In-PR This issue has a related PR label Aug 24, 2022
@zadjii-msft zadjii-msft modified the milestones: Backlog, Terminal v1.17 Aug 25, 2022
zadjii-msft added a commit that referenced this issue Apr 6, 2023
…alization" (#13811)

This is a revert of the revert of #12979. We mainly reverted that PR
because of an issue where restored windows would grow/shrink slightly on
external displays. It was too close to the ship date for that release,
so we backed it out wholesale (in #13098). I think I've found the real
root of the problem, and fixed it here.

The money diff here from the original PR:
4c08b9a...c34495d.
Basically, I had put the part where we actually handle the creation of
the window into `_AppInitializedHandler`, when we should have left the
window to be created in `_HandleCreateWindow` We create it there,
_hidden_, and then should only _show_ it in `_AppInitializedHandler`.

I'm _NOT_ incorporating the change for #9053. I reverted that bit in
1fac403. I am too worried about that messing with the phwnd that I
wanted to get that reviewed and committed atomically, separately.

* fixes  #11561
* tested manually
* I work here
microsoft-github-policy-service bot pushed a commit that referenced this issue Apr 18, 2023
…ute (#13838)

Original description, pre-process model v3:

> This is just the `SHOWDEFAULT` bit from #12979. This seems to also
work now, but I'm PR'ing it separately so it can be a separate revert
from #13811, if it is problematic.

More accurately: 
This PR enables terminal windows to use the `wShowCmd` from the
STARTUPINFO passed to `windowsterminal.exe` to set the initial
visibility of the window. We can't just use `SW_SHOWDEFAULT`, because
all the windows are running in the initial process! After the first
window, the subsequent ones would ignore any params passed to their
originating `windowsterminal.exe` processes. To mitigate, we pass that
`wShowCmd` info from the source process, to the actual running terminal
process. That accounts for most of the delta here.

Closes #9053


This doesn't do the same for defterm-initiated connections. This is
because we don't need to! Defterm very explicitly rejects handoff for
minimized console apps. This is probably for the best! I put an attempt
in 66f8b25 before I forgot that it was filtered long before the
Terminal. NOT doing this for /min saves us all sorts of "what happens if
`start /min cmd` tries to glom?" or "what if someone does `start /min
cmd && start /max cmd` and they glom together?".

<hr>

Also closes #15193, which was introduced as a part of this.

---------

Co-authored-by: Dustin L. Howett <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-UserInterface Issues pertaining to the user interface of the Console or Terminal Help Wanted We encourage anyone to jump in on these. In-PR This issue has a related PR Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-2 A description (P2) Product-Terminal The new Windows Terminal.
Projects
None yet
5 participants