Conversation
This comment was marked as resolved.
This comment was marked as resolved.
DHowett
left a comment
There was a problem hiding this comment.
Chatted offline, there might be a better way. However, I love the signature changes and clarifying comments. We should keep those.
…fterm-focus-foreground
| { | ||
| uint32_t sizeInBytes; | ||
| uint32_t processId; | ||
| uint32_t processId; // THIS IS A HANDLE, NOT A PID |
|
Nits: When you prep this as a commit message, remove the commit IDs from the body (they aren't meaningful once squashed), and remove the original notes about the thing we didn't do / the summary/details section |
…fterm-focus-foreground
|
Moved from body: See also: #12799, the origin of much of this. This change evolved over multiple phases. Part the first (4de1ef7)When we create a defterm connection in To remedy this, we need to:
Part the second (5ab0799)DefTerm launches don't actually request focus mode, so the Terminal never sends them focus events. We need those focus events so that the console can request foreground rights. To remedy this, we need to:
|
There was a problem hiding this comment.
I love this PR. The comments are great and explain the problems well.
What --resizeQuirk and --win32input mean is not that well explained in this PR and might be hard to understand for newcomers, but I believe that this is clearly out of scope for the PR.
|
Hello @DHowett! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
See also: #12799, the origin of much of this. This change evolved over multiple phases. When we create a defterm connection in `TerminalPage::_OnNewConnection`, we don't have the hosting HWND yet, so the tab gets created without one. We'll later get called with the owner, in `Initialize`. To remedy this, we need to: * In `Initialize`, make sure to update any existing controls with the new owner. * In `ControlCore`, actually propogate the new owner down to the connection DefTerm launches don't actually request focus mode, so the Terminal never sends them focus events. We need those focus events so that the console can request foreground rights. To remedy this, we need to: * pass `--win32input` to the commandline used to initialize OpenConsole in ConPTY mode. We request focus events at the same time we request win32-input-mode. * I also added `--resizeQuirk`, because _by all accounts that should be there_. Resizing in defterm windows should be _wacky_ without it, and I'm a little surprised we haven't seen any bugs due to this yet. `ConsoleSetForeground` expects a `HANDLE` to the process we want to give foreground rights to. The problem is, the wire format we used _also_ decided that a HANDLE value was a good idea. It's not. If we pass the literal value of the HANDLE to the process from OpenConsole to conhost, so conhost can call that API, the value that conhost uses there will most likely be an invalid handle. The HANDLE's value is its value in _OpenConsole_, not in conhost. To remedy this, we need to: * Just not forward `ConsoleSetForeground`. Turns out, we _can_ just call that in OpenConsole safely. There's no validation. So just instantiate a static version of the Win32 version of ConsoleControl, just to use for SetForeground. (thanks Dustin) * [x] Tested manually - Win+R `powershell`, `notepad` spawns on top. Closes #13211 (cherry picked from commit 2a7dd8b) Service-Card-Id: 83026847 Service-Version: 1.14
|
🎉 Handy links: |
|
🎉 Handy links: |
See also: #12799, the origin of much of this.
This change evolved over multiple phases.
Part the first
When we create a defterm connection in
TerminalPage::_OnNewConnection,we don't have the hosting HWND yet, so the tab gets created without one.
We'll later get called with the owner, in
Initialize.To remedy this, we need to:
Initialize, make sure to update any existing controls with thenew owner.
ControlCore, actually propogate the new owner down to theconnection
Part the second
DefTerm launches don't actually request focus mode, so the Terminal
never sends them focus events. We need those focus events so that the
console can request foreground rights.
To remedy this, we need to:
--win32inputto the commandline used to initialize OpenConsolein ConPTY mode. We request focus events at the same time we request
win32-input-mode.
--resizeQuirk, because by all accounts that should bethere. Resizing in defterm windows should be wacky without it, and
I'm a little surprised we haven't seen any bugs due to this yet.
Part the third
ConsoleSetForegroundexpects aHANDLEto the process we want to giveforeground rights to. The problem is, the wire format we used also
decided that a HANDLE value was a good idea. It's not. If we pass the
literal value of the HANDLE to the process from OpenConsole to conhost,
so conhost can call that API, the value that conhost uses there will
most likely be an invalid handle. The HANDLE's value is its value in
OpenConsole, not in conhost.
To remedy this, we need to:
Just not forward
ConsoleSetForeground. Turns out, we can just callthat in OpenConsole safely. There's no validation. So just instantiate
a static version of the Win32 version of ConsoleControl, just to use
for SetForeground. (thanks Dustin)
Tested manually - Win+R
powershell,notepadspawns on top.Closes #13211