2020-05-07 18:00:56 +02:00
|
|
|
<?xml version="1.0" encoding="utf-8"?>
|
|
|
|
|
|
|
|
<Package
|
|
|
|
xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"
|
|
|
|
xmlns:mp="http://schemas.microsoft.com/appx/2014/phone/manifest"
|
2020-05-29 00:02:40 +02:00
|
|
|
xmlns:com="http://schemas.microsoft.com/appx/manifest/com/windows10"
|
2020-05-07 18:00:56 +02:00
|
|
|
xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10"
|
|
|
|
xmlns:uap3="http://schemas.microsoft.com/appx/manifest/uap/windows10/3"
|
|
|
|
xmlns:uap4="http://schemas.microsoft.com/appx/manifest/uap/windows10/4"
|
Add startup task, setting to launch application on login (#4908)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
This PR adds a new boolean global setting, startOnUserLogin, along with associated AppLogic to request enabling or disabling of the StartupTask. Added UAP5 extensions to AppX manifests.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#2189
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #2189
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [x] Requires documentation to be updated
* [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #2189
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Please note, I'm a non-practicing C++ developer, there are a number of things I wasn't sure how to handle in the appropriate fashion, mostly around error handling and what probably looks like an incredibly naive (and messy) way to implement the async co_await behavior.
Error handling-wise, I found (don't ask me how!) that if you somehow mismatch the startup task's ID between the manifest and the call to `StartupTask::GetAsync(hstring taskId)`, you'll get a very opaque WinRT exception that boils down to a generic invalid argument message. This isn't likely to happen in the wild, but worth mentioning...
I had enough trouble getting myself familiarized with the project, environment, and C++/WinRT in general didn't want to try to tackle adding tests for this quite yet since (as I mentioned) I don't really know what I'm doing. I'm happy to give it a try with perhaps a bit of assistance in getting started 😃
Further work in this area of the application outside of this immediate PR might need to include adding an additional setting to contain launch args that the startup task can pass to the app so that users can specify a non-default profile to launch on start, window position (e.g., #653).
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
✔️ Default settings:
Given the user does not have the `startOnUserLogin` setting in their profile.json,
When the default settings are opened (via alt+click on Settings),
Then the global settings should contain the `"startOnUserLogin": false` token
✔️ Applying setting on application launch
Given the `startOnUserLogin` is `true` and
the `Windows Terminal` startup task is `disabled` and
the application is not running
When the application is launched
Then the `Windows Terminal` entry in the user's Startup list should be `enabled`
✔️ Applying setting on settings change
Given the `startOnUserLogin` is `true` and
the `Windows Terminal` startup task is `enabled` and
the application is running
When the `startOnUserLogin` setting is changed to `false` and
the settings file is saved to disk
Then the `Windows Terminal` startup task entry should be `disabled`
✔️ Setting is ignored when user has manually disabled startup
Given the `startOnUserLogin` is `true` and
the application is not running and
the `Windows Terminal` startup task has been set to `disabled` via user action
When the application is launched
Then the startup task should remain disabled and
the application should not throw an exception
#### note: Task Manager does not seem to re-scan startup task states after launch; the Settings -> Apps -> Startup page also requires closing or moving away to refresh the status of entries
2020-06-01 22:24:43 +02:00
|
|
|
xmlns:uap5="http://schemas.microsoft.com/appx/manifest/uap/windows10/5"
|
2020-05-29 00:18:35 +02:00
|
|
|
xmlns:uap7="http://schemas.microsoft.com/appx/manifest/uap/windows10/7"
|
2020-05-07 18:00:56 +02:00
|
|
|
xmlns:desktop="http://schemas.microsoft.com/appx/manifest/desktop/windows10"
|
2020-05-29 00:02:40 +02:00
|
|
|
xmlns:desktop4="http://schemas.microsoft.com/appx/manifest/desktop/windows10/4"
|
|
|
|
xmlns:desktop5="http://schemas.microsoft.com/appx/manifest/desktop/windows10/5"
|
2020-05-07 18:00:56 +02:00
|
|
|
xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
|
2021-02-19 03:12:16 +01:00
|
|
|
IgnorableNamespaces="uap mp rescap uap3">
|
2020-05-07 18:00:56 +02:00
|
|
|
|
|
|
|
<Identity
|
|
|
|
Name="Microsoft.WindowsTerminalPreview"
|
|
|
|
Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US"
|
|
|
|
Version="0.5.0.0" />
|
|
|
|
|
|
|
|
<Properties>
|
2020-06-09 20:32:27 +02:00
|
|
|
<DisplayName>Windows Terminal Preview</DisplayName>
|
2020-05-07 18:00:56 +02:00
|
|
|
<PublisherDisplayName>Microsoft Corporation</PublisherDisplayName>
|
|
|
|
<Logo>Images\StoreLogo.png</Logo>
|
|
|
|
</Properties>
|
|
|
|
|
|
|
|
<Dependencies>
|
2021-05-20 18:04:25 +02:00
|
|
|
<TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.18362.0" MaxVersionTested="10.0.19041.0" />
|
2020-05-07 18:00:56 +02:00
|
|
|
</Dependencies>
|
|
|
|
|
|
|
|
<Resources>
|
|
|
|
<Resource Language="x-generate"/>
|
|
|
|
</Resources>
|
|
|
|
|
|
|
|
<Applications>
|
|
|
|
<Application Id="App"
|
|
|
|
Executable="$targetnametoken$.exe"
|
|
|
|
EntryPoint="$targetentrypoint$">
|
|
|
|
<uap:VisualElements
|
|
|
|
DisplayName="ms-resource:AppNamePre"
|
|
|
|
Description="ms-resource:AppDescriptionPre"
|
|
|
|
BackgroundColor="transparent"
|
|
|
|
Square150x150Logo="Images\Square150x150Logo.png"
|
|
|
|
Square44x44Logo="Images\Square44x44Logo.png">
|
|
|
|
<uap:DefaultTile
|
2020-05-28 17:42:13 +02:00
|
|
|
Wide310x150Logo="Images\Wide310x150Logo.png"
|
2020-05-07 18:00:56 +02:00
|
|
|
Square71x71Logo="Images\SmallTile.png"
|
|
|
|
Square310x310Logo="Images\LargeTile.png"
|
|
|
|
ShortName="ms-resource:AppShortNamePre">
|
|
|
|
<uap:ShowNameOnTiles>
|
|
|
|
<uap:ShowOn Tile="square150x150Logo"/>
|
2020-05-29 00:02:40 +02:00
|
|
|
<uap:ShowOn Tile="wide310x150Logo"/>
|
2020-05-07 18:00:56 +02:00
|
|
|
<uap:ShowOn Tile="square310x310Logo"/>
|
|
|
|
</uap:ShowNameOnTiles>
|
|
|
|
</uap:DefaultTile>
|
|
|
|
</uap:VisualElements>
|
|
|
|
|
|
|
|
<Extensions>
|
2020-07-11 00:41:37 +02:00
|
|
|
<uap3:Extension Category="windows.appExecutionAlias" Executable="wt.exe" EntryPoint="Windows.FullTrustApplication">
|
2020-05-07 18:00:56 +02:00
|
|
|
<uap3:AppExecutionAlias>
|
|
|
|
<desktop:ExecutionAlias Alias="wt.exe" />
|
|
|
|
</uap3:AppExecutionAlias>
|
|
|
|
</uap3:Extension>
|
2021-02-19 03:12:16 +01:00
|
|
|
<uap3:Extension Category="windows.appExtensionHost">
|
|
|
|
<uap3:AppExtensionHost>
|
|
|
|
<uap3:Name>com.microsoft.windows.terminal.settings</uap3:Name>
|
|
|
|
</uap3:AppExtensionHost>
|
|
|
|
</uap3:Extension>
|
Add startup task, setting to launch application on login (#4908)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
This PR adds a new boolean global setting, startOnUserLogin, along with associated AppLogic to request enabling or disabling of the StartupTask. Added UAP5 extensions to AppX manifests.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#2189
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #2189
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [x] Requires documentation to be updated
* [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #2189
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Please note, I'm a non-practicing C++ developer, there are a number of things I wasn't sure how to handle in the appropriate fashion, mostly around error handling and what probably looks like an incredibly naive (and messy) way to implement the async co_await behavior.
Error handling-wise, I found (don't ask me how!) that if you somehow mismatch the startup task's ID between the manifest and the call to `StartupTask::GetAsync(hstring taskId)`, you'll get a very opaque WinRT exception that boils down to a generic invalid argument message. This isn't likely to happen in the wild, but worth mentioning...
I had enough trouble getting myself familiarized with the project, environment, and C++/WinRT in general didn't want to try to tackle adding tests for this quite yet since (as I mentioned) I don't really know what I'm doing. I'm happy to give it a try with perhaps a bit of assistance in getting started 😃
Further work in this area of the application outside of this immediate PR might need to include adding an additional setting to contain launch args that the startup task can pass to the app so that users can specify a non-default profile to launch on start, window position (e.g., #653).
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
✔️ Default settings:
Given the user does not have the `startOnUserLogin` setting in their profile.json,
When the default settings are opened (via alt+click on Settings),
Then the global settings should contain the `"startOnUserLogin": false` token
✔️ Applying setting on application launch
Given the `startOnUserLogin` is `true` and
the `Windows Terminal` startup task is `disabled` and
the application is not running
When the application is launched
Then the `Windows Terminal` entry in the user's Startup list should be `enabled`
✔️ Applying setting on settings change
Given the `startOnUserLogin` is `true` and
the `Windows Terminal` startup task is `enabled` and
the application is running
When the `startOnUserLogin` setting is changed to `false` and
the settings file is saved to disk
Then the `Windows Terminal` startup task entry should be `disabled`
✔️ Setting is ignored when user has manually disabled startup
Given the `startOnUserLogin` is `true` and
the application is not running and
the `Windows Terminal` startup task has been set to `disabled` via user action
When the application is launched
Then the startup task should remain disabled and
the application should not throw an exception
#### note: Task Manager does not seem to re-scan startup task states after launch; the Settings -> Apps -> Startup page also requires closing or moving away to refresh the status of entries
2020-06-01 22:24:43 +02:00
|
|
|
<uap5:Extension Category="windows.startupTask">
|
|
|
|
<uap5:StartupTask
|
|
|
|
TaskId="StartTerminalOnLoginTask"
|
|
|
|
Enabled="false"
|
|
|
|
DisplayName="ms-resource:AppNamePre" />
|
|
|
|
</uap5:Extension>
|
2021-03-26 23:09:49 +01:00
|
|
|
<uap3:Extension Category="windows.appExtension">
|
|
|
|
<uap3:AppExtension Name="com.microsoft.windows.console.host"
|
|
|
|
Id="OpenConsole-Pre"
|
|
|
|
DisplayName="OpenConsole Preview"
|
|
|
|
Description="Console host built from microsoft/terminal open source repository"
|
|
|
|
PublicFolder="Public">
|
|
|
|
<uap3:Properties>
|
|
|
|
<Clsid>{06EC847C-C0A5-46B8-92CB-7C92F6E35CD5}</Clsid>
|
|
|
|
</uap3:Properties>
|
|
|
|
</uap3:AppExtension>
|
|
|
|
</uap3:Extension>
|
|
|
|
<uap3:Extension Category="windows.appExtension">
|
|
|
|
<uap3:AppExtension Name="com.microsoft.windows.terminal.host"
|
|
|
|
Id="Terminal-Pre"
|
|
|
|
DisplayName="Windows Terminal Preview"
|
|
|
|
Description="Terminal host built from microsoft/terminal open source repository"
|
|
|
|
PublicFolder="Public">
|
|
|
|
<uap3:Properties>
|
|
|
|
<Clsid>{86633F1F-6454-40EC-89CE-DA4EBA977EE2}</Clsid>
|
|
|
|
</uap3:Properties>
|
|
|
|
</uap3:AppExtension>
|
|
|
|
</uap3:Extension>
|
|
|
|
<com:Extension Category="windows.comInterface">
|
|
|
|
<com:ComInterface>
|
|
|
|
<com:ProxyStub Id="1833E661-CC81-4DD0-87C6-C2F74BD39EFA" DisplayName="OpenConsoleHandoffProxy" Path="OpenConsoleProxy.dll"/>
|
Persist inbox conhost; delegate control activities to it via a pipe (#10415)
Persist inbox conhost; delegate control activities to it via a pipe
## PR Checklist
* [x] Closes #10194 - WSL Debug Tap doesn't work
* [x] Closes #10134 - WSL Parameter is Incorrect
* [x] Closes #10413 - Ctrl+C not passed to client
* [x] Closes #10414 - Leftover processes on abrupt termination
* [x] Might help #10251 - Win+X Powershell sometimes fails to attach
* [x] I work here
* [x] Manually tested with assorted launch scenarios
## Detailed Description of the Pull Request / Additional comments
It turns out that there's a bit of ownership that goes on with the original inbox `conhost.exe` and the operating system/driver. The PID of that original `conhost.exe` is stowed when the initial connection is established and it is verified for several activities. This means that the plan of letting it go completely away and having the `OpenConsole.exe` take over all of its activities must be slightly revised.
I have tested the following two alternatives to keeping `conhost.exe` around and they do not work:
1. Replacing the original owner `conhost.exe` with `OpenConsole.exe` - A.) The driver does not allow this. Once the owner is registered, it cannot be replaced. B.) There's no way of updating this information inside the client process space and it is kept there too in the `kernelbase`/`conclnt` data from its initial connection.
2. Attempting to pick up the first packet (to determine headed/headless and other initial connection information that we use to determine whether handoff is appropriate or not) prior to registering any owner at all. - The driver doesn't allow this either. The owner must be registered prior to a packet coming through.
Put this mental model in your head:
CMD --> Conhost (inbox) --> OpenConsole (WT Package) --> Terminal (WT Package)
So since the `conhost.exe` needs to stick around, here's what I'm doing in this PR:
- `conhost.exe` in the OS will receive back the `OpenConsole.exe` process handle on a successful handoff and is expected to remain alive until the `OpenConsole.exe` exits. It's now waiting on that before it terminates itself.
- `conhost.exe` in the OS will establish a signal channel pipe and listen for control commands from `OpenConsole.exe` in a very similar fashion to how the `ConPTY` signal pipe operates between the Terminal and the PTY (provided by `OpenConsole.exe` in this particular example.) When `OpenConsole.exe` needs to do something that would be verified by the OS and rejected... it will instead signal the original `conhost.exe` to do that thing and it will go through.
- `conhost.exe` will give its own handle through to `OpenConsole.exe` so it can monitor its lifetime and cleanup. If the owner is gone, the session should end.
- Assorted handle cleanup that was leading to improper exits. I was confused between `.reset()` and `.release()` for some of the `wil::unique_any<T>` handling and it lead to leaked handles. The leaked handles meant that threads weren't aware of the other sides collapsing and wouldn't cleanup/terminate appropriately.
How does this fix things?
- For the WSL cases... WSL was specifically looking up the owner PID of the console session from the driver. That was the `conhost.exe` PID. If it exits, that PID isn't valid and is recycled. Thus the parameter is incorrect or other inappropriate WSL setup behaviors.
- Ctrl+C not passed... this is a signal the operating system rejects from a PID that is not the owner. This is now relayed through the original owner and it works.
- Leftover processes... I believe I explained this was both not-enough-monitoring of each others' process lifetimes coupled with mishandling of release/resetting handles and leaking them.
- Powershell sometimes fails to attach... my theory on this one is that it's a race that became upset when the `conhost.exe` disappeared while something about Powershell/.NET was still starting, much like the WSL one. I believe now that it is sticking around, it will be fine.
Also, this WILL require an OS update to complete improvement of functionality and I have revised the interface ID. This is considered an acceptable breaking change with no mitigation because we said this feature was an alpha preview.
## Validation Steps Performed
- Launched WSL with defapp set, it works
- Launched WSL with defapp set and the debug tap on, it works and opens in two tabs
- Launched CMD, ran ping, did Ctrl+C, it now receives it
- Launched Win+X powershell a ton of times. It seems fine now
- Launched cmd, powershell, wsl, etc. Killed assorted processes in the chain (client/conhost/openconsole/windowsterminal) and observed in Process Explorer (with a long delta timer so I could see it) that they all successfully tear down now without leftovers.
2021-06-16 21:23:37 +02:00
|
|
|
<com:Interface Id="E686C757-9A35-4A1C-B3CE-0BCC8B5C69F4" ProxyStubClsid="1833E661-CC81-4DD0-87C6-C2F74BD39EFA"/>
|
2021-05-24 23:56:46 +02:00
|
|
|
<com:Interface Id="59D55CCE-FC8A-48B4-ACE8-0A9286C6557F" ProxyStubClsid="1833E661-CC81-4DD0-87C6-C2F74BD39EFA"/>
|
2021-03-26 23:09:49 +01:00
|
|
|
</com:ComInterface>
|
|
|
|
</com:Extension>
|
2020-05-28 17:42:13 +02:00
|
|
|
<com:Extension Category="windows.comServer">
|
|
|
|
<com:ComServer>
|
2021-03-26 23:09:49 +01:00
|
|
|
<com:ExeServer DisplayName="OpenConsole" Executable="OpenConsole.exe">
|
|
|
|
<com:Class Id="06EC847C-C0A5-46B8-92CB-7C92F6E35CD5"/>
|
|
|
|
</com:ExeServer>
|
2021-03-29 19:23:20 +02:00
|
|
|
<com:ExeServer DisplayName="WindowsTerminal" Executable="WindowsTerminal.exe">
|
2021-03-26 23:09:49 +01:00
|
|
|
<com:Class Id="86633F1F-6454-40EC-89CE-DA4EBA977EE2"/>
|
|
|
|
</com:ExeServer>
|
2020-05-28 17:42:13 +02:00
|
|
|
<com:SurrogateServer DisplayName="WindowsTerminalShellExt">
|
2021-03-17 21:32:45 +01:00
|
|
|
<com:Class Id="02db545a-3e20-46de-83a5-1329b1e88b6b" Path="WindowsTerminalShellExt.dll" ThreadingModel="STA"/>
|
2020-05-28 17:42:13 +02:00
|
|
|
</com:SurrogateServer>
|
|
|
|
</com:ComServer>
|
|
|
|
</com:Extension>
|
|
|
|
<desktop4:Extension Category="windows.fileExplorerContextMenus">
|
|
|
|
<desktop4:FileExplorerContextMenus>
|
|
|
|
<desktop5:ItemType Type="Directory">
|
2021-03-17 21:32:45 +01:00
|
|
|
<desktop5:Verb Id="OpenTerminalPre" Clsid="02db545a-3e20-46de-83a5-1329b1e88b6b" />
|
2020-05-28 17:42:13 +02:00
|
|
|
</desktop5:ItemType>
|
|
|
|
<desktop5:ItemType Type="Directory\Background">
|
2021-03-17 21:32:45 +01:00
|
|
|
<desktop5:Verb Id="OpenTerminalPre" Clsid="02db545a-3e20-46de-83a5-1329b1e88b6b" />
|
2020-05-28 17:42:13 +02:00
|
|
|
</desktop5:ItemType>
|
|
|
|
</desktop4:FileExplorerContextMenus>
|
|
|
|
</desktop4:Extension>
|
|
|
|
|
2020-05-07 18:00:56 +02:00
|
|
|
</Extensions>
|
|
|
|
|
|
|
|
</Application>
|
|
|
|
</Applications>
|
|
|
|
|
|
|
|
<Capabilities>
|
|
|
|
<Capability Name="internetClient" />
|
|
|
|
<rescap:Capability Name="runFullTrust" />
|
|
|
|
</Capabilities>
|
|
|
|
|
|
|
|
<Extensions>
|
|
|
|
<uap7:Extension Category="windows.sharedFonts">
|
|
|
|
<uap7:SharedFonts>
|
|
|
|
<uap4:Font File="Cascadia.ttf" />
|
|
|
|
<uap4:Font File="CascadiaMono.ttf" />
|
|
|
|
</uap7:SharedFonts>
|
|
|
|
</uap7:Extension>
|
|
|
|
</Extensions>
|
|
|
|
</Package>
|