Switching OS input method resets Terminal colors and zoom

Windows Terminal version (or Windows build number)

Windows 11
Version: 10.0.22000.258

Windows Terminal Preview
Version: 1.11.2731.0

Other Software

Bash (in WSL)

Steps to reproduce

Inside a xterm terminal, override the terminal's colors using escape sequences such as:
```
# Set "red" color to hex(ab4642)
printf '\033]4;%d;rgb:%s\033\\' 1 'ab/46/42';
# Set "background" color to hex(181818)
printf '\033]%d;rgb:%s\033\\' 11 '18/18/18';
```
The full theme I use can be applied using the following script https://github.com/fnune/base16-shell/blob/master/scripts/base16-default-dark.sh. This method allows me to conveniently switch between dark and light themes, regardless of the OS I'm currently using.
Assuming you have multiple input methods configured in Windows (e.g. I switch between "US" and "US-International" regularly), press either Ctrl+Shift or Win+Space to switch between input methods.

Switching input from the task bar using the mouse also triggers this bug.

Expected Behavior

Switching input methods in Windows has no impact on the configuration of my open Terminal sessions.

Actual Behavior

The terminal's colors get reset to the color scheme configured in Terminal for the current session.

Before switching input methods:

After switching input methods:

Hmm. This is a decent point. We reload the settings when we get a keyboard layout change. This is important for things like the actions, who might need to be re-parsed for different keys in the new layout. But this is something that's totally unrelated that's getting blown away.

I'm running into a similar issue with the work in ragnarok for #5000. If you set the colors with VT, then hot-reload the settings, we'll remove the changes to those colors. (same with font size, opacity, anything that can get changed at runtime really). The question is - does a change to the settings override a runtime change by the user? And I think I'm leaning "it probably shouldn't". But then you get into weird things like "should 'preview color scheme' still work on top of the user setting the colors with VT" and then I lean "yes it should"

I think it is acceptable to expect the settings to be reloaded when certain things change.

I was just surprised to see something, which seemed unrelated to me, cause a reload in Terminal.

If this is not something that can (or should) be avoided, I'm also fine closing as "works as intended". At least the issue should contain enough keywords for someone to find it if they run into a similar issue.

I think I'm actually gonna leave this open. I think I've got an idea in my notes for now to get this to work. Setting the colors with VT will set a runtime "colors have been overridden" flag, and previewing a scheme will clear that flag out. But a plain-old settings reload, that won't touch that flag, so that'll allow the vt-set colors to persist across hot-reloads of the settings. We might be able to get even more precise and determine that the color scheme for a profile changed, and in that scenario, also clear out the flag.

A bunch of work really, but definitely possible.

Setting the colors with VT will set a runtime "colors have been overridden" flag, and previewing a scheme will clear that flag out.

Can't we just make it so that the settings dialog only updates properties that have actually been edited in some way? So if you change the color scheme for a profile, or edit something on the Color Schemes page, that'll override any colors that have been set programmatically, but if you edit something unrelated (like say the Actions page), then we leave the colors as they are.

This applies to other settings as well. If some application has left the cursor switched to an underscore when your preference is a block, you should be able to go to the Appearance page and reapply your preference by toggling the value or perhaps just clicking Save. It doesn't seem reasonable to me for an application to lock in changes to things like colors and the cursor so your only recourse is to close the tab and start again.

Following the principle of least astonishment:

If you edit something on the Actions page in the settings, would you be surprised if that also caused the colors in the terminal to be reset? I think the answer is probably "yes" (as seen from this issue), but perhaps not hugely surprising when you think about what might have triggered that change.
If you try and change the color scheme for your profile, would you be surprised if that didn't have any effect, just because some app sent a palette-altering VT sequence at some point in the past? In this case I think the answer is definitely "yes", and it would almost certainly be seen as a bug, because it's not at all obvious why it would have failed.

Can't we just make it so that the settings dialog only updates properties that have actually been edited in some way? So if you change the color scheme for a profile, or edit something on the Color Schemes page, that'll override any colors that have been set programmatically, but if you edit something unrelated (like say the Actions page), then we leave the colors as they are.

I would love that. Unfortunately we don't really have the architecture in place at the moment to say "this part of the settings changed" 😞

Unfortunately we don't really have the architecture in place at the moment to say "this part of the settings changed"

I get that, but I thought what you were proposing was going to take a bunch of work anyway, and would be a step backwards for the second scenario I described (assuming I've understood you correctly). So if anyone is going to be spending significant time on trying to fix this, it would be nice to try and get it right (assuming we're in agreement on what "right" is).

It could be something simple like saving the settings we care about (e.g. colors and cursor shapes) when the dialog is opened, and then when the user saves, you only apply those settings to any open tabs if the values have changed from what they were at the start.

Jay Cap (@mrjcap)

Since this has been open for a while and the most recent fix attempts (#14498, #19933) never landed, I spent a day instrumenting the reload path to get hard numbers on what it actually costs. The instrumentation, a self-contained reproducer, and a full writeup live on this branch (not a PR — explicitly a sitting investigation branch):

https://github.com/Skydev0h/terminal/tree/investigation/gh11522-layout-switch-lag

Measured cost

Captured on an i9-14900K / 96 GB DDR5-6600 / Windows 11 24H2 at ~1.15 GB private-bytes stressed state (40 tabs × 10 000 scrollback lines each, reproducible in under a minute via the bundled stress-tab.ps1):

SettingsChanged.raise synchronously blocks the UI thread for 3400–3700 ms per reload. Saturated at this state — scales with tabs × scrollback × pattern-scanner lock contention against ControlCore::UpdatePatternLocations, not raw memory size.
First reload after any meaningful state change leaks +329 to +633 MB private bytes. Subsequent reloads oscillate within ±30 MB as previous CascadiaSettings/TerminalSettings/ControlSettings/ControlAppearance generations get GC'd.
Working set stays flat at ~670 MB while private commit climbs to 2.5 GB — meaning a steady-state real-world user who has been accumulating reload-path garbage for days eats hard-fault cost on top of the 3.5 s base freeze.

Memory bloat and layout-switch lag are the same bug

Multiple comments on this thread and adjacent issues (#19249, #10609) describe the host process growing to gigabytes over days of uptime. The instrumentation makes the connection direct: each reload triggered by LanguageProfileNotifier::OnActivated (AppLogic.cpp:151-189) leaks through the same path that causes the visible lag. A user who switches layouts several dozen times a day over a week reaches GB-scale accumulation naturally. When the ReloadSettingsThrottled() call in that callback is skipped (local WT_GH11522_SKIP=1 env-var toggle in the branch), lag drops to unmeasurable and private bytes stay flat at 1165 MB across 40+ rapid layout events at identical state.

5-minute reproducer

Build the branch above as Dev SKU (lives side-by-side with Stable under WindowsTerminalDev_8wekyb3d8bbwe / wtd.exe)
1..40 | ForEach-Object { wtd -w 0 nt powershell -NoExit -File stress-tab.ps1; Start-Sleep -Milliseconds 150 } (file path should be adjusted to the absolute path or file should be in your user directory)
Launch DebugView as admin, Capture → Capture Global Win32, filter *GH11522*
Click a tab, Win+Space — observe interleaved layout-change / reload-done elapsed=~3500ms pairs and the frozen UI
setx WT_GH11522_SKIP 1, fully restart Dev WT host, re-stress, Win+Space — observe zero reload-done, stable private bytes, instant layout switching

Note for anyone who doesn't want to build: replacing wtd with wt in step 2 runs the same stress against stock Stable Windows Terminal and reproduces the 3+ second freeze identically — you just don't get the elapsed numbers from the instrumentation. If you have at least two different layouts installed and a few minutes, you can verify the symptom without cloning the branch.

Full call-chain walkthrough, data tables, DebugView A/B screenshots, and sketches of three escalating fix tiers (including an extension of Jay Cap (@mrjcap)'s approach in #19933 to also cover VkKeyScanW-based OEM-punct bindings through a char → chord sidecar in ActionMap) are in wt-keyboard-layout-lag-investigation.md on the same branch.

Suggested next step

#19933's approach was the right direction and mrjcap addressed all review feedback in the same day — it was never clear from outside why it closed without merge two weeks later. A revival (possibly extended to cover OEM-punct for full character-consistency preservation) would kill both the lag and the memory bloat in one change. Happy to help with the OEM-punct extension work if someone with merge authority wants to pick it back up.

Separate finding surfaced by the instrumentation (filing as its own issue, not to derail this one): til::ThrottledFunc debounce prevents scheduling multiple reloads while the timer is pending, but does not prevent re-fire for events arriving during the reload function's execution. Rapidly spamming Win+Space during the 3.5 s freeze reliably chains two back-to-back reloads for 7+ seconds of frozen UI. Nine layout-change events in 625 ms → two reload-done events totaling 7.2 s — captured in the writeup linked above.

Keep the font size delta across settings reloads (#20230)

Alright, I have done this issue somewhat of a disservice. For the longest time, we have been closing mostly reports of "the font size resets when xyz happens" as duplicates of this issue. Now I've fixed that in #20320 (which I'll backport to all existing versions, don't worry.)

The problem is, this issue also tracks the color palette.

Font size is easier. The CLI application can't change it, and there's an explicit reset button you can press to undo changes. Cache the zoom level and re-apply it regardless of the underlying settings; this will not overwrite anything except the user's own preferences. Fine.

Color can be changed by the CLI application almost exclusively and the user at the console can't reset the palette to default. I am hesitant to remove what feels like the only way to restore the colors when an application has left them messed up (by jiggling the settings.)

My tab's color gets reset to the default several times a day (so I have to have the script running in that tab change the color again and again), not because I need to change the keyboard layout, but because I have to fix the issue at https://aka.ms/AAjpd0w, using https://gist.github.com/sba923/a71dd721e78ae08842616db244f19437#file-remove-uselesskeyboardlayouts-ps1 which I run from my profile. So basically (almost) every time I launch a new tab the color for some other tab gets reset...

Edit: And, yes, now I know what the cause is: the zoom factor of all tabs is reset to 100%, way more annoying than the aforementioned tab color issue!

Keep the font size delta across settings reloads (#20230)

Besides colors, there also remains the problem with the cursor, which also resets on IM change. This constantly hinders work with modal text editors like Neovim, which switch between different cursors in different contexts and use them to indicate modes.

Besides colors, there also remains the problem with the cursor, which also resets on IM change. This constantly hinders work with modal text editors like Neovim, which switch between different cursors in different contexts and use them to indicate modes.

That's indeed more than annoying, this just makes those editors very problematic to use!

Microsoft (@microsoft): again, without this bug https://aka.ms/AAjpd0w (490 upvotes today...), the present issue would not be triggered that often! 😒

Additional reproduction and UI-thread CPU profiling data for the multi-second layout-switch freeze in #20389 / #20517, on Windows Terminal Preview 1.25.1912.0, Windows 11 build 22631.6199 (captured 2026-09-15).

Reproduction and controls

With 1-3 tabs, switching EN/RU is fast. With roughly 10 or more tabs/panes, it takes several seconds; recent manually observed stalls reach approximately 7 seconds. Characters typed during the stall appear together after it ends.
It also happens when the layout is changed outside Terminal: leave Terminal on EN, focus Notepad, switch Notepad to RU, then return to Terminal and type. Returning without changing the language is fast in the control test, including subsequent tab selection.
Enabling Windows' "Let me use a different input method for each app window" preserved Terminal's previously selected visible input language, but did not prevent the freeze after changing language in Notepad and returning. The setting was reverted after this test.
Notepad remains responsive during equivalent EN/RU switching. WezTerm with many tabs also switches promptly on this machine.
The symptom occurs with both WSL shells and PowerShell in WT. A separate portable copy of the same Preview, with ten newly created cmd.exe /d tabs, also reproduced it. That window had its own process/UI thread and the input target was confirmed. Existing working WT windows remained open, and the test tabs had explicit tab colors; this was not a test with every other WT process shut down.
experimental.detectURLs is confirmed false in the installed Preview's active root settings. Splitting the existing tabs across several windows did not resolve the symptom.

CPU profile of an actual reproduction

One 60-second WPR capture used GeneralProfile + XAMLAppResponsiveness while more than ten actual EN/RU switches and input stalls were reproduced in the installed Preview. The relevant HWND was mapped to the process and UI thread before analysis. Analysis was restricted to the first 60 seconds, excluding final rundown/merge. TerminalApp symbols matched the installed module's PDB identity.

The CPU-only stack report contains 41,431 samples for that UI thread:

Frame/module	Samples	Share
`TerminalPage::_updateThemeColors` (inclusive)	39,779	96.01%
`Tab::_ApplyTabColorOnUIThread` (inclusive)	39,759	95.96%
`Tab::_RefreshVisualState` (inclusive)	33,942	81.92%
`Windows.UI.Xaml.dll` (exclusive by module)	30,925	74.64%

Inclusive rows overlap and must not be added. These are CPU-sample shares, not elapsed freeze durations. Individual physical layout switches were not separately timestamped in this ETW capture, and capture overhead is a limitation.

Source path matching the profile

In tag v1.25.1912.0:

AppLogic.cpp:151-154: LanguageProfileNotifier calls ReloadSettingsThrottled().
TerminalPage.cpp:1974-1980: a control's PropertyChanged("BackgroundBrush") calls _updateThemeColors().
TerminalPage.cpp:4952-5050: that method traverses tabs/panes and applies colors to all tab items.
Tab.cpp:2556-2577: _RefreshVisualState() changes RequestedTheme Light -> Dark -> previous value, followed by visual-state transitions.

This suggests that repeated control notifications during a settings reload amplify full tab/theme refresh work. The profile localizes the dominant CPU cost; it does not establish an exact complexity law or number of invalidations per language switch.

Could the repeated theme invalidations be coalesced or unchanged state skipped while the layout-dependent keybinding work is addressed? Would you prefer this profiling evidence to stay under #11522, or should the theme-refresh amplification be tracked separately?

The raw ETL remains local because it was captured during working sessions; only the extracted counts and public source references are included here.

Follow-up with an actual locally built and manually tested candidate patch for the multi-second EN/RU UI freeze.

Result: on the affected machine, the patched Preview build switches EN/RU normally with 10 tabs, where the ordinary Preview repeatedly freezes. Session restoration also works after enabling it in the portable configuration. This is a daily-workflow blocker: around ten tabs is a normal workload, and a language change should not stop all input for several seconds on a modern desktop. Please prioritize investigating the repeated theme refresh work below.

Reproduction and comparison

Windows Terminal Preview 1.25.1912.0, Windows 11 22631.6199.
1-3 tabs: switching is quick. Around 10+ tabs/panes: multiple-second stalls, up to approximately 7 seconds by manual observation; typed characters appear together afterward.
Also reproduced by changing EN/RU in Notepad and returning to Terminal. Returning with the same language is quick. Notepad and WezTerm with many tabs are quick on the same machine.
The freeze was reproduced in PowerShell and in a separate stock portable instance with ten fresh cmd.exe /d tabs; it does not require Linux shell configuration or an LLM application.
The patched Release/x64 portable build was tested in ten WT-FIX tabs and tested again after a WSL restart. EN/RU switching remained responsive. The owner also confirmed the subsequent daily settings and tab restoration work.
This is owner-observed behavior, not a measured milliseconds benchmark. Other Terminal instances remained open in earlier tests. A stock-vs-patched test with byte-identical current settings and a complete UI regression suite have not been completed. The report does not isolate the contribution of each of the two changes.

What changed

The preceding comment includes symbol-matched WPR evidence: _updateThemeColors accounted for 96.01% of 41,431 UI-thread CPU samples, inclusive, not 96% of elapsed freeze time.

The candidate keeps the language notification/settings reload path and keyboard mapping intact:

During the all-tabs settings update, suppress intermediate window-wide theme refreshes and retain the existing final refresh. An RAII scope restores the flag, including on exceptions.
In TermControl::_coreBackgroundColorChanged, notify BackgroundBrush only when the brush identity or relevant color changes. Handle solid and acrylic tint/fallback colors; continue updating the light/dark contrast state even when no notification is needed.

The complete three-file diff below is against upstream tag v1.25.1912.0, base 1cea42d. It exactly matches the patch packaged with the tested local build. It is proposed code for review, not a claim of an upstream-ready fix for every symptom in this issue.

Build: Release/x64, MSVC 14.41.34120, Windows SDK 10.0.22621.0; build completed with 0 errors and 70 warnings. Full upstream tests and clean-machine deployment were not run. Further review should include high-contrast/theme changes, acrylic, tab colors, focused/unfocused panes, shortcuts, and notification reentrancy.

Complete candidate patch (3 files)

diff --git a/src/cascadia/TerminalApp/TerminalPage.cpp b/src/cascadia/TerminalApp/TerminalPage.cpp
index e5b238e..279042f 100644
--- a/src/cascadia/TerminalApp/TerminalPage.cpp
+++ b/src/cascadia/TerminalApp/TerminalPage.cpp
@@ -3901,24 +3901,34 @@ namespace winrt::TerminalApp::implementation
         // up the previous ones we built.
         _terminalSettingsCache->Reset(_settings);
 
-        for (const auto& tab : _tabs)
+        // Each pane can raise BackgroundBrush changes while applying settings.
+        // Defer their window-wide theme updates until the final refresh below,
+        // instead of refreshing every tab for every pane in this loop.
         {
-            if (auto tabImpl{ _GetTabImpl(tab) })
+            const auto wasUpdating = std::exchange(_updatingTerminalSettings, true);
+            const auto restoreUpdating = wil::scope_exit([&]() {
+                _updatingTerminalSettings = wasUpdating;
+            });
+
+            for (const auto& tab : _tabs)
             {
-                // Let the tab know that there are new settings. It's up to each content to decide what to do with them.
-                tabImpl->UpdateSettings(_settings);
+                if (auto tabImpl{ _GetTabImpl(tab) })
+                {
+                    // Let the tab know that there are new settings. It's up to each content to decide what to do with them.
+                    tabImpl->UpdateSettings(_settings);
 
-                // Update the icon of the tab for the currently focused profile in that tab.
-                // Only do this for TerminalTabs. Other types of tabs won't have multiple panes
-                // and profiles so the Title and Icon will be set once and only once on init.
-                _UpdateTabIcon(*tabImpl);
+                    // Update the icon of the tab for the currently focused profile in that tab.
+                    // Only do this for TerminalTabs. Other types of tabs won't have multiple panes
+                    // and profiles so the Title and Icon will be set once and only once on init.
+                    _UpdateTabIcon(*tabImpl);
 
-                // Force the TerminalTab to re-grab its currently active control's title.
-                tabImpl->UpdateTitle();
-            }
+                    // Force the TerminalTab to re-grab its currently active control's title.
+                    tabImpl->UpdateTitle();
+                }
 
-            auto tabImpl{ winrt::get_self<Tab>(tab) };
-            tabImpl->SetActionMap(_settings.ActionMap());
+                auto tabImpl{ winrt::get_self<Tab>(tab) };
+                tabImpl->SetActionMap(_settings.ActionMap());
+            }
         }
 
         if (const auto focusedTab{ _GetFocusedTabImpl() })
@@ -4951,6 +4961,11 @@ namespace winrt::TerminalApp::implementation
 
     void TerminalPage::_updateThemeColors()
     {
+        if (_updatingTerminalSettings)
+        {
+            return;
+        }
+
         if (_settings == nullptr)
         {
             return;
diff --git a/src/cascadia/TerminalApp/TerminalPage.h b/src/cascadia/TerminalApp/TerminalPage.h
index 67ed4a7..2ef43e1 100644
--- a/src/cascadia/TerminalApp/TerminalPage.h
+++ b/src/cascadia/TerminalApp/TerminalPage.h
@@ -228,6 +228,7 @@ namespace winrt::TerminalApp::implementation
         winrt::TerminalApp::ColorPickupFlyout _tabColorPicker{ nullptr };
 
         Microsoft::Terminal::Settings::Model::CascadiaSettings _settings{ nullptr };
+        bool _updatingTerminalSettings{ false };
 
         Windows::Foundation::Collections::IObservableVector<TerminalApp::Tab> _tabs;
         Windows::Foundation::Collections::IObservableVector<TerminalApp::Tab> _mruTabs;
diff --git a/src/cascadia/TerminalControl/TermControl.cpp b/src/cascadia/TerminalControl/TermControl.cpp
index 2ea1ff9..da26920 100644
--- a/src/cascadia/TerminalControl/TermControl.cpp
+++ b/src/cascadia/TerminalControl/TermControl.cpp
@@ -1156,18 +1156,20 @@ namespace winrt::Microsoft::Terminal::Control::implementation
             bg = Windows::UI::Colors::Transparent();
         }
 
-        if (auto acrylic = RootGrid().Background().try_as<Media::AcrylicBrush>())
+        const auto brush = RootGrid().Background();
+        auto changed = brush != _BackgroundBrush;
+        if (auto acrylic = brush.try_as<Media::AcrylicBrush>())
         {
+            changed = changed || til::color{ acrylic.FallbackColor() } != bg || til::color{ acrylic.TintColor() } != bg;
             acrylic.FallbackColor(bg);
             acrylic.TintColor(bg);
         }
-        else if (auto solidColor = RootGrid().Background().try_as<Media::SolidColorBrush>())
+        else if (auto solidColor = brush.try_as<Media::SolidColorBrush>())
         {
+            changed = changed || til::color{ solidColor.Color() } != bg;
             solidColor.Color(bg);
         }
 
-        BackgroundBrush(RootGrid().Background());
-
         // Don't use the normal BackgroundBrush() Observable Property setter
         // here. (e.g. `BackgroundBrush()`). The one from the macro will
         // automatically ignore changes where the value doesn't _actually_
@@ -1176,9 +1178,13 @@ namespace winrt::Microsoft::Terminal::Control::implementation
         // Color() of the brush. This results in the event not getting bubbled
         // up.
         //
-        // Firing it manually makes sure it does.
-        _BackgroundBrush = RootGrid().Background();
-        PropertyChanged.raise(*this, Data::PropertyChangedEventArgs{ L"BackgroundBrush" });
+        // Notify for changes to either identity or color, but not for a redraw
+        // that reports the same background color again.
+        _BackgroundBrush = brush;
+        if (changed)
+        {
+            PropertyChanged.raise(*this, Data::PropertyChangedEventArgs{ L"BackgroundBrush" });
+        }
 
         _isBackgroundLight = _isColorLight(bg);
     }

Could a maintainer review this coalescing/unchanged-notification approach and advise whether it belongs here or in a separate performance PR? A merged fix in an official release would let affected users stop maintaining a private build just to type in more than one language.

Keep the font size delta across settings reloads (microsoft#20230)

Follow-up to the full patch and ten-tab test: the same user has now tested the patched build with 50 open terminals and reports that the former RU/EN freezes are gone. The user explicitly identified the build containing the layout patch plus our separate clipboard changes. This is user-observed acceptance on one Windows 11 PC, not an instrumented latency benchmark or an upstream regression-suite result.

Automatic URL detection has also been re-enabled; Ctrl+click works and language switching remains responsive. We are no longer relying on disabling URL detection as a workaround.

The layout patch is still the diff in the linked comment, based on v1.25.1912.0 / 1cea42d433253d95c4487a3037db48197b5e72f4. It defers redundant window-wide theme updates during settings application, preserves the existing final refresh, and avoids redundant background-brush notifications while retaining actual color/acrylic changes. It does not suppress language-change notifications or settings reload wholesale.

Before the patch, ordinary RU/EN switching with many tabs could stall input for around seven seconds; changing language outside Terminal and returning could also trigger it. The earlier WPR sample analysis and its limitations are in the preceding comments. We have preserved the accepted portable runtime and settings for recovery, without claiming a fresh clean-Windows test or a full stock/patched comparison with identical current settings.

As checked on 2026-09-20, the newest published Preview remains 1.25.1912.0 and this issue remains open. Could a maintainer review this fix and advise on the required regression coverage/upstream PR? The repeated user tests suggest a substantial usability improvement for people keeping many long-lived terminal sessions open. Happy to follow the project's preferred test approach; this is evidence for the performance fix, not a claim that every color/zoom-reset symptom in this issue is resolved.

HARPCODE DEVELOPER (@pavelbe)

HARPCODE DEVELOPER (@pavelbe) please follow the AI contributing guidelines on this repo. This applies to your other issue report as well.

Windows Terminal: keep tab colors through Terminal's own color resets…

Majority of users use bilingual keyboard and Alt+Shift to change language. This bug fires dozens of times an hour.

Example: Far Manager. Far's maintainers confirmed the cause is Terminal and sent users here: FarGroup/FarManager#1138

I understand the concern that a settings reload is the only way to recover a palette an app left broken. But here nothing is broken: the app is still running and relies on the palette it set. The user didn't touch any setting, they only typed in another language.

Navigation Menu

Repository navigation

Switching OS input method resets Terminal colors and zoom #11522

Windows Terminal version (or Windows build number)

Other Software

Steps to reproduce

Expected Behavior

Actual Behavior

33 remaining items

Measured cost

Memory bloat and layout-switch lag are the same bug

5-minute reproducer

Suggested next step

Reproduction and controls

CPU profile of an actual reproduction

Source path matching the profile

Reproduction and comparison

What changed

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Switching OS input method resets Terminal colors and zoom #11522

Description

Windows Terminal version (or Windows build number)

Other Software

Steps to reproduce

Expected Behavior

Actual Behavior

Activity

zadjii-msft commented on Oct 18, 2021

antoineco commented on Oct 18, 2021

zadjii-msft commented on Oct 19, 2021

j4james commented on Oct 19, 2021

zadjii-msft commented on Oct 19, 2021

j4james commented on Oct 19, 2021

33 remaining items

Skydev0h commented on Apr 11, 2026

Measured cost

Memory bloat and layout-switch lag are the same bug

5-minute reproducer

Suggested next step

DHowett commented on May 15, 2026

sba923 commented on Jun 2, 2026

Omenabaka commented on Jun 14, 2026

sba923 commented on Jun 15, 2026

pavelbe commented on Sep 15, 2026

Reproduction and controls

CPU profile of an actual reproduction

Source path matching the profile

pavelbe commented on Sep 15, 2026

Reproduction and comparison

What changed

pavelbe commented on Sep 19, 2026

DHowett commented on Sep 20, 2026

drweb86 commented on Oct 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions