No longer load content dialogs when there is already one being shown #12517
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ghost
added
Area-Settings UI
PankajBhojwani
commented
Feb 17, 2022
lhecker
reviewed
Feb 17, 2022
…/pabhoj/close_tabs_dialog
lhecker
approved these changes
Feb 18, 2022
zadjii-msft
approved these changes
Feb 18, 2022
PankajBhojwani
added
the
AutoMerge
|
Hello @PankajBhojwani! 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 (
|
ghost
merged commit 
DHowett
added
the
zPreview-Service-Queued-1.13
DHowett
reviewed
Feb 18, 2022
| DefaultButton="Primary" /> | ||
|
|
||
| <ContentDialog x:Name="ControlNoticeDialog" | ||
| x:Uid="ControlNoticeDialog" | ||
| x:Load="False" | ||
| CloseButtonClick="_DialogCloseClick" |
There was a problem hiding this comment.
hey does this still work when the user presses Esc?
There was a problem hiding this comment.
Yep! We still end up in TerminalPage::_DialogCloseClick upon hitting Esc
1 task
ghost
pushed a commit
that referenced
this pull request
Mar 10, 2022
DHowett
pushed a commit
that referenced
this pull request
Mar 10, 2022
…12517) ## Summary of the Pull Request Somehow, the controls v2 update caused an issue where if you as much as _load_ a content dialog when there's already one open, we get holes in the terminal window (#12447) This commit introduces logic to `TerminalPage` to check whether there is a content dialog open before we try to load another one. ## PR Checklist * [x] Closes #12447 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema updated. * [x] I work here ## Validation Steps Performed Can no longer repro #12447 (cherry picked from commit 788d33c)
DHowett
pushed a commit
that referenced
this pull request
Mar 10, 2022
zadjii-msft
pushed a commit
that referenced
this pull request
Mar 10, 2022
…12517) Somehow, the controls v2 update caused an issue where if you as much as _load_ a content dialog when there's already one open, we get holes in the terminal window (#12447) This commit introduces logic to `TerminalPage` to check whether there is a content dialog open before we try to load another one. * [x] Closes #12447 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [ ] Tests added/passed * [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx * [ ] Schema updated. * [x] I work here Can no longer repro #12447
zadjii-msft
added a commit
that referenced
this pull request
Mar 10, 2022
|
🎉 Handy links: |
ghost
mentioned this pull request
This was referenced Apr 6, 2022
ghost
pushed a commit
that referenced
this pull request
Apr 6, 2022
…#12840) After switching to ControlsV2, it seems that delay-loading a dialog causes the ContentDialog to be assigned a Height equal to it's content size. If we DON'T assign the ContentDialog a Row, I believe it's assigned Row 0 by default. So, when the dialog gets opened, the dialog seemingly causes a giant hole to appear in the body of the app. Assigning all the dialogs to Row 2 (where the rest of the content is) makes the "hole" appear in the same space as the rest of the TabContent, fixing the issue. Note that the actual content in a content dialog gets parented to the PopupRoot, so it actually always appeared in the correct place, it's just this weird hole that appeared in Row 0. * [x] Closes #12775 * See also: * #12202 was fixed by #12208 * #12447 was fixed by #12517 * [x] Tested manually * [x] Reverts #12625 * [x] Reverts #12517
DHowett
pushed a commit
that referenced
this pull request
Apr 6, 2022
…#12840) After switching to ControlsV2, it seems that delay-loading a dialog causes the ContentDialog to be assigned a Height equal to it's content size. If we DON'T assign the ContentDialog a Row, I believe it's assigned Row 0 by default. So, when the dialog gets opened, the dialog seemingly causes a giant hole to appear in the body of the app. Assigning all the dialogs to Row 2 (where the rest of the content is) makes the "hole" appear in the same space as the rest of the TabContent, fixing the issue. Note that the actual content in a content dialog gets parented to the PopupRoot, so it actually always appeared in the correct place, it's just this weird hole that appeared in Row 0. * [x] Closes #12775 * See also: * #12202 was fixed by #12208 * #12447 was fixed by #12517 * [x] Tested manually * [x] Reverts #12625 * [x] Reverts #12517 (cherry picked from commit c4e5ebf) Service-Card-Id: 80266902 Service-Version: 1.12
DHowett
pushed a commit
that referenced
this pull request
Apr 6, 2022
…#12840) After switching to ControlsV2, it seems that delay-loading a dialog causes the ContentDialog to be assigned a Height equal to it's content size. If we DON'T assign the ContentDialog a Row, I believe it's assigned Row 0 by default. So, when the dialog gets opened, the dialog seemingly causes a giant hole to appear in the body of the app. Assigning all the dialogs to Row 2 (where the rest of the content is) makes the "hole" appear in the same space as the rest of the TabContent, fixing the issue. Note that the actual content in a content dialog gets parented to the PopupRoot, so it actually always appeared in the correct place, it's just this weird hole that appeared in Row 0. * [x] Closes #12775 * See also: * #12202 was fixed by #12208 * #12447 was fixed by #12517 * [x] Tested manually * [x] Reverts #12625 * [x] Reverts #12517 (cherry picked from commit c4e5ebf) Service-Card-Id: 80266903 Service-Version: 1.13
This pull request was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary of the Pull Request
Somehow, the controls v2 update caused an issue where if you as much as load a content dialog when there's already one open, we get holes in the terminal window (#12447)
This commit introduces logic to
TerminalPageto check whether there is a content dialog open before we try to load another one.PR Checklist
Validation Steps Performed
Can no longer repro #12447