UX REGRESSION - Pasting 5kb of text causes half of the terminal to become transparent #12775
Labels
Area-UserInterface
Issues pertaining to the user interface of the Console or Terminal
Issue-Bug
It either shouldn't be doing this or needs an investigation.
Priority-1
A description (P1)
Product-Terminal
The new Windows Terminal.
Resolution-Fix-Committed
Fix is checked in, but it might be 3-4 weeks until a release.
Severity-Blocking
We won't ship a release like this! No-siree.
zAskModeBug
Milestone
Comments
jtschuster
added
the
Issue-Bug
ghost
added
Needs-Triage
|
Okay, we've "fixed" this enough times that I'm marking this sev-blocking until we get to the actual root cause 😄 |
zadjii-msft
added
Area-UserInterface
This comment was marked as outdated.
This comment was marked as outdated.
|
Notes:
|
4 tasks
ghost
added
Resolution-Fix-Committed
ghost
pushed a commit
that referenced
this issue
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 issue
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 issue
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
DHowett
changed the title
DHowett
added
zAskModeBug
Priority-1
|
🎉This issue was addressed in #12840, which has now been successfully released as Handy links: |
|
🎉This issue was addressed in #12840, which has now been successfully released as Handy links: |
zadjii-msft
added a commit
that referenced
this issue
May 23, 2022
ThemeResources are a persistent pain. Regressed in #13083. See also #12775 et. al. We can't just put those here though as StaticResources, because XAML will evaluate their values when the App is first loaded, and we'll always use the value from the OS theme, regarless of the requested theme. Kinda the same thing we've had to do with TabViewBackground in the past. * [x] Fixes something we noticed right before shipping
1 task
ghost
pushed a commit
that referenced
this issue
May 23, 2022
ThemeResources are a persistent pain. Regressed in #13083. See also #12775 et. al. We can't just put those here though as StaticResources, because XAML will evaluate their values when the App is first loaded, and we'll always use the value from the OS theme, regarless of the requested theme. Kinda the same thing we've had to do with TabViewBackground in the past. * [x] Fixes something we noticed right before shipping
DHowett
pushed a commit
that referenced
this issue
May 23, 2022
ThemeResources are a persistent pain. Regressed in #13083. See also #12775 et. al. We can't just put those here though as StaticResources, because XAML will evaluate their values when the App is first loaded, and we'll always use the value from the OS theme, regarless of the requested theme. Kinda the same thing we've had to do with TabViewBackground in the past. * [x] Fixes something we noticed right before shipping (cherry picked from commit bb03b00) Service-Card-Id: 82303612 Service-Version: 1.14
DHowett
pushed a commit
that referenced
this issue
May 23, 2022
ThemeResources are a persistent pain. Regressed in #13083. See also #12775 et. al. We can't just put those here though as StaticResources, because XAML will evaluate their values when the App is first loaded, and we'll always use the value from the OS theme, regarless of the requested theme. Kinda the same thing we've had to do with TabViewBackground in the past. * [x] Fixes something we noticed right before shipping (cherry picked from commit bb03b00) Service-Card-Id: 82303611 Service-Version: 1.13
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Windows Terminal version
1.13.10734.0
Windows build number
10.0.22581.0
Other Software
No response
Steps to reproduce
Copy over 5kb of text, then paste it into windows terminal
Expected Behavior
The terminal should not change appearance
Actual Behavior
The top half of the window becomes fully transparent for every tab.The text was updated successfully, but these errors were encountered: