Conversation
(cherry picked from commit 46c6403)
(cherry picked from commit 5614fde95f927428a6acc38baeea64588953c2a5)
I think this is a fix for #12190 intentionally, and for #12169 by happenstance. I'm no longer creating the window when the actions at the commandline are just creating new tabs or panes that need to be elevated. I still have more to check here. For ex: ``` wtd nt -p admin ; sp -p admin ; sp -p foo ``` That... should create a new tab then split that with foo, right? Unsure if that'll work * [ ] fix that * [ ] I don't think I need HookupKeyBindings
This comment has been minimized.
This comment has been minimized.
|
I've checked out and built this branch and can no longer reproduce the crash in #12169 🎉. |
|
@ianjoneill thanks for going the extra mile to confirm! (and also for selfhosting directly on |
DHowett
left a comment
There was a problem hiding this comment.
This seems like a very thorny area in which we're gonna continue seeing issues -- let's monitor.
| // - <none> | ||
| // Return Value: | ||
| // - <none> | ||
| bool TerminalPage::ShouldImmediatelyHandoffToElevated(CascadiaSettings& settings) const |
There was a problem hiding this comment.
This doesn't seem to need a mutable reference to settings. Make it a const ref?
Same for the one below.
| // - This is a bit of trickiness: If we're running unelevated, and the user | ||
| // passed in only --elevate actions, the we don't _actually_ want to | ||
| // restore the layouts here. We're not _actually_ about to create the | ||
| // window. We're simply going to toss the commandlines |
There was a problem hiding this comment.
Just so I get it: This returns true if we're not elevated but all relevant pane-spawning actions are elevated. Is that correct? Would such a comment be helpful for others in the future?
|
Hello @zadjii-msft! 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 (
|
There are a couple places where we now bail immediately on startup, if we think the window is going to get created without any tabs. We do that to prevent a blank window from flashing on the screen when launching auto-elevate profiles. Unfortunately, those broke defterm in a particularly hard to debug way. In the defterm invocation, there actually aren't any tabs when the app completes initialization. We use the initialization to actually accept the defterm handoff. So what would happen is that the window would immediately close itself gracefully, never accepting the handoff. In my defense, #8514, the original auto-elevated PR, predates defterm merging (906edf7) by a few months, so I totally forgot to test this when rolling it into the subsequent iterations of that PR. * Related to: * #7489 * #12137 * #12205 * [x] Closes #12267 * [x] I work here * [ ] No tests on this code unfortunately * [x] Tested manually Includes a semi-related code fix to #10922 to make that quieter. That is perpetually noisy, and when trying to debug defterm, you've only got about 30s to do that before it bails, so the `sxe eh` breaks in there are quite annoying.
(cherry picked from commit dd213a5)
|
🎉 Handy links: |
This is a collection of fixes:
split-paneto a new tab, in the case that it's preceded with onlynew-tabactions that opened elevated windows.checklist