-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
"You are about to close a read-only terminal" popup does not appear if I select "Close Tab" from the menu again #9502
Comments
TerminalPage::_ShowCloseReadOnlyDialog is called from two functions:
TerminalPage::_RemoveTab is called from four functions:
TerminalPage::_RemoveTabViewItem, TerminalPage::_CloseFocusedTab, and TerminalPage::_CloseFocusedPane discard the IAsyncAction returned by TerminalPage::_RemoveTab, instead of awaiting it. Does that cause the coroutine to be aborted so that some cleanup is skipped? |
Huh. That's weird. Not totally sure why, but that's definitely happening. Thanks! /cc @Don-Vito this seems like the kind of thing that interests you 😋 |
If discarding the IAsyncAction really causes this, then can the compiler be made to warn about such usage, perhaps by making C++/WinRT emit |
@zadjii-msft - please assign to me 😄 |
So the problem is that click on the "close tab" goes directly for the tab->rootPane->Close(), rather than asking the TerminalPage to remove the tab (which is not very successful design decision IMHO). Unfortunately, Pane::Close sets isClosing to true, even if the closing is dismissed, and as a result the next invocations of Pane::Close do nothing:
|
## Summary of the Pull Request Currently a repeated attempt to close a read-only tab from context menu, will bring the terminal into invalid state if user dismisses close action. There are two root causes for this: 1. The tab close menu triggers the closing of the root pane (rather than invoking close tab flow in the Terminal Page). 2. Currently panes are not aware that the closing was canceled, and thus they trigger the Closed event, putting the system in a weird state, where the Closed handlers were invoked, but the Pane remains. This PR mitigates #9502, by addressing the first root cause (the fix is trivial and hopefully can be serviced). Moreover, it addresses the only existing UI flow that can trigger the issue. The remaining problematic flow will occur when the connection is closed. I have created a separate Issue to track it: #9572 as I guess the PR for it might be more complex. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #9502 * [x] CLA signed. * [ ] Tests added/passed * [ ] Documentation updated. * [ ] Schema updated. * [ ] I've discussed this with core contributors already. (cherry picked from commit a5ff745)
🎉This issue was addressed in #9571, which has now been successfully released as Handy links: |
🎉This issue was addressed in #9571, which has now been successfully released as Handy links: |
Environment
Steps to reproduce
Expected behavior
The same warning should pop up again.
Actual behavior
The warning does not pop up and the tab does not close.
Notes
If you try to close the pane by pressing Ctrl+Shift+W or choosing "Close pane" from the command palette, then that pops up the warning each time.
Related to #6981.
The text was updated successfully, but these errors were encountered: