-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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
Ignore closeOnExit when a conn. moves from Connecting to Failed #10263
Conversation
ConptyConnection has two different failure modes: 1. We failed to initialize the pseudoconsole or create the process 2. The process exited with an error code. Until this commit, they were treated the same way: closeOnExit=always would force the pane/tab to be destroyed. This was very bad in case 1, where we would display a (possibly useful) error message and then immediately close the window. This was made even worse by the change in #10045. We removed startingDirectory validation and promoted it to an error message (so that we could eventually let the connection handle startingDirectory in its own way.) This of course revealed that a number of users had set invalid starting directories… and those users included some who set closeOnExit to always. Boom: instant "terminal opens and crashes"¹ ¹ It only looks like a crash; it's actually _technically_ functioning properly. Closes #10225.
@@ -1476,6 +1486,7 @@ std::pair<std::shared_ptr<Pane>, std::shared_ptr<Pane>> Pane::_Split(SplitState | |||
// Move our control, guid into the first one. | |||
// Move the new guid, control into the second. | |||
_firstChild = std::make_shared<Pane>(_profile.value(), _control); | |||
_firstChild->_connectionState = std::exchange(_connectionState, ConnectionState::NotConnected); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it just me or is it kinda hacky that this isn't part of the/a constructor?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I rather think the design of Pane leaves a lot to be desired; there are a lot of properties that "move" between parent and leaf panes. The ideal design is one that doesn't require us to move state at all. I'd rather not spend too much effort on an already-bad solution 😄
ConptyConnection has two different failure modes: 1. We failed to initialize the pseudoconsole or create the process 2. The process exited with an error code. Until this commit, they were treated the same way: closeOnExit=always would force the pane/tab to be destroyed. This was very bad in case 1, where we would display a (possibly useful) error message and then immediately close the window. This was made even worse by the change in #10045. We removed startingDirectory validation and promoted it to an error message (so that we could eventually let the connection handle startingDirectory in its own way.) This of course revealed that a number of users had set invalid starting directories… and those users included some who set closeOnExit to always. Boom: instant "terminal opens and crashes"¹ In this commit, we introduce detection for a connection that fails before it's been established. When that happens, we will ignore the user's closeOnExit mode. ¹ It only looks like a crash; it's actually _technically_ functioning properly. Closes #10225. (cherry picked from commit 31d78dc)
🎉 Handy links: |
🎉 Handy links: |
ConptyConnection has two different failure modes:
Until this commit, they were treated the same way: closeOnExit=always
would force the pane/tab to be destroyed. This was very bad in case 1,
where we would display a (possibly useful) error message and then
immediately close the window.
This was made even worse by the change in #10045. We removed
startingDirectory validation and promoted it to an error message (so
that we could eventually let the connection handle startingDirectory in
its own way.) This of course revealed that a number of users had set
invalid starting directories… and those users included some who set
closeOnExit to always. Boom: instant "terminal opens and crashes"¹
¹ It only looks like a crash; it's actually technically functioning
properly.
Closes #10225.