-
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
Toggling Legacy console on and off enables Terminal colors but sets them to all black #2319
Comments
Definitely a real bug. |
AHHHH That explains how to get into this state. I've seen it in the wild once in a blue moon, but never figured out how to repro it. THANK YOU for figuring out how to get into this state. WE can work with this :) |
(preliminary thoughts without debugging) This might happen either with a shortcut or a registry entry. We might be able to get away with looking to see if those settings are present. When the v1 console is saving the settings, it's probably not zeroing those settings. It's probably removing the keys from the shortcut entirely. We might be able to get away with having the console use I'd really doubt actually that this happens when opening the settings from the registry - the v1 conhost shouldn't set those reg keys to 0, since it won't know what they even are. Maybe there's a chance that Worst case, we could check if all 3 of default foreground, default background, and cursor color are all 0. If all 3 are zero, we could take that as a sign that the settings were erroneously zero'd, and reset all of them to INVALID_COLOR. That would get rid of the technically valid state of wanting all three to be black, but what kind of monster would want that? |
…lack background. (#2651) * This fixes the registry path What's happening is the console is writing the Forcev2 setting, then the v1 console is ignoring those settings, then when you check the checkbox to save the v2 settings, we'll write the zeros out. That's obviously bad. So we'll only write the v2 settings back to the registry if the propsheet was launched from a v2 console. This does not fix the shortcut path. That'll be the next commit. * Fix the shortcut loading too fixes #2319 * remove the redundant property I added * add some notes to the bx.ps1 change
…lack background. (#2651) * This fixes the registry path What's happening is the console is writing the Forcev2 setting, then the v1 console is ignoring those settings, then when you check the checkbox to save the v2 settings, we'll write the zeros out. That's obviously bad. So we'll only write the v2 settings back to the registry if the propsheet was launched from a v2 console. This does not fix the shortcut path. That'll be the next commit. * Fix the shortcut loading too fixes #2319 * remove the redundant property I added * add some notes to the bx.ps1 change (cherry picked from commit b97db63)
- Fix snapping to the cursor in "Terminal Scrolling" mode (GH-2705) fixes GH-1222 PSReadline calls SetConsoleCursorPosition on each character. We try to snap. However, we'd only ever do this with the visible viewport, the viewport defined by `SCREEN_INFORMATION::_viewport`. When there's a virtual viewport in Terminal Scrolling mode, we actually need to snap the virtual viewport, so that this behavior looks more regular. (cherry picked from commit 6f4b98a) - Passthrough BEL in conpty (GH-2990) fixes GH-2952. (cherry picked from commit 6831120) - make filling chars (and, thus, erase line/char) unset wrap (GH-2831) EraseInLine calls `FillConsoleOutputCharacterW()`. In filling the row with chars, we were setting the wrap flag. We need to specifically not do this on ANY _FILL_ operation. Now a fill operation UNSETS the wrap flag if we fill to the end of the line. Originally, we had a boolean `setWrap` that would mean... - **true**: if writing to the end of the row, SET the wrap value to true - **false**: if writing to the end of the row, DON'T CHANGE the wrap value ,- current wrap value | ,- fill last cell? | | ,- new wrap value | | | ,- comments |-|-|-| |1|0|0| THIS CASE WAS UNHANDLED To handle that special case (1-0-0), we need to UNSET the wrap. So now, we have ~setWrap~ `wrap` mean the following: - **true**: if writing to the end of the row, SET the wrap value to TRUE - **false**: if writing to the end of the row, SET the wrap value to FALSE - **nullopt**: leave the wrap value as it is Closes GH-1126 (cherry picked from commit 4dd9f9c) - When reverse indexing, preserve RGB/256 attributes (GH-2987) (cherry picked from commit 847d6b5) - do not allow CUU and CUD to move "across" margins. (GH-2996) If we're moving the cursor up, its vertical movement should be stopped at the top margin. Similarly, this applies to moving down and the bottom margin. Fixes GH-2929. (cherry picked from commit 0ce08af) - Prevent the v1 propsheet from zeroing colors, causing black text on black background. (GH-2651) fixes GH-2319 (cherry picked from commit b97db63) - Render the cursor state to VT (GH-2829) (cherry picked from commit a9f3849) - Don't put NUL in the buffer in VT mode (GH-3015) (cherry picked from commit a82d6b8) - Return to ground when we flush the last char (GH-2823) The InputStateMachineEngine was incorrectly not returning to the ground state after flushing the last sequence. That means that something like alt+backspace would leave us in the Escape state, not the ground state. This makes sure we return to ground. Additionally removes the "Parser.UnitTests-common.vcxproj" file, which was originally used for a theoretical time when we only open-sourced the parser. It's unnecessary now, and we can get rid of it. Also includes a small patch to bcz.cmd, to make sure bx works with projects with a space in their name. (cherry picked from commit 53c81a0) - Add support for passing through extended text attributes, like… (GH-2917) ... Related work items: #23678919, #23678920, #23731910, #23731911, #23731912, #23731913, #23731914, #23731915, #23731916, #23731917, #23731918
Hey! The fix for this went out in Windows in the Insider channel's Fast Ring with build 19013. |
Shouldn't you reopen this one? |
From our perspective, this bug is fixed. The fix will be available in the next version of Windows. The workaround is easy, and we do not service bug fixes for bugs with easy workarounds unless somebody can provide a significant business justification. |
I see no workaround and there is no way to turn the fonts to any color other than black, nor the background colors whatsoever. It makes the V2 console completely unusable. |
I gave you a workaround in the other thread you started about this issue. Go to the Terminal settings page and turn off all of the “separate color” options. |
It worked. Thank you. |
Default behavior should NEVER break applications. That is extremely bad UX. A workaround is never a resolution. |
@linuxandria it’s a workaround for somebody to get out of this state without upgrading Windows to resolve the bug. It’s not a default state. It’s a bug. That’s why we fixed it. |
I feel your statement could be better worded to mean that. From my interpretation, you are saying (excl one sentence where you say the opposite) that this will not be fixed, because it has a workaround. I do apologize for any misunderstanding but you really should strive for maximum clarity. We can't all read your thought :P |
Sorry 😄 |
Environment
Microsoft Windows [Version 10.0.18362.239]
Steps to reproduce
1.Open a CMD
2.Settings > Options > Check Legacy
3.Restart CMD
4.Settings > Options > Uncheck Legacy
5.Restart CMD
6.Get a full black screen.
Actual behavior
Screenshot from Settings after the steps to reproduce.
What's actually happening?
The problem is that i run a script on shutting down my computer which is for backup and ask me in a CMD if i want to backup my files.
Since the new update, this CMD is all black. So i just know what there is written, but i can't see it actually.
I think this causes from this bug.
The text was updated successfully, but these errors were encountered: