Cannot type in new pane or tab until focus is manually activated with mouse click

Windows Terminal version
1.14.1451.0
Windows build number
10.0.19042.0
Other Software
No response
Steps to reproduce
Create new pane/new tab
Expected Behavior
It is possible to type in the newly opened terminal
Actual Behavior
Unable to type until I click on the new terminal.
Note that enabling the option "Automatically focus pane on mouse hover" partially prevents the issue from happening.
It seems like focus is removed from all terminal tabs/panes whenever a new one is created.

I can't reproduce this issue, unless it's an initial launch of WSL. Does your issue happen with WSL or with any shell?

Hey, thanks for having a look at this. At the moment I can reproduce it with both WSL and Powershell profiles. However it's a lot less consistent than I thought initially.
It doesn't make much sense, but mostly, after starting a new terminal, new tabs/panes are working fine (apart from the initial launch of WSL as you also noticed). However, if I switch to a different window for some time (seems like around a minute is enough, but 30 seconds is not), then go back to Windows Terminal (using Alt+Tab or mouse doesn't make a difference), I can experience the issue.
At the moment the option "Automatically focus pane on mouse hover" is disabled, so I don't think that was necessarily making any difference like I said in the initial report.
In case it helps, I'm attaching my settings.json
winterm-settings.json.zip

I have an issue that might be related. If I open a terminal from the Start menu in Windows 11 by typing to search for "terminal", it almost always appears under other windows and fails to get focus. If I just click on the pinned icon in the Start menu without typing, this never happens. Opening a terminal with Win-x i also gets focus correctly, as does Ctrl-Shift-n from another terminal. This seems to be consistent with both Terminal (1.13.11432.0) and Terminal Preview (1.15.1863.0).
My default profile is WSL, in case that makes a difference. The issue affects any new windows regardless of how many terminals I have open.

same issue here, cannot seem to get the focus on a newly opened tab

I'm gonna focus in on the PowerShell repro case here. The fact that the Terminal loses focus when a WSL tab is opened is a well-known bug (I believe in WSLg).
I don't have any idea why this would happen. @praimmugen when the terminal does get into this state (where apparently nothig is focused), what does pressing tab do? That should move focus to the "next" UI element, which might help us figure out where focus is currently.

when the terminal does get into this state (where apparently nothig is focused), what does pressing tab do? That should move focus to the "next" UI element, which might help us figure out where focus is currently.

Unfortunately, pressing tab has no effect - I can't see anything getting focus no matter how many times I press the key.

I'm gonna focus in on the PowerShell repro case here. The fact that the Terminal loses focus when a WSL tab is opened is a well-known bug (I believe in WSLg).

Not sure it changes things, but in my case focus is also lost when opening new WSL panes within a tab.

Is there anything in your PowerShell profile? If pressing tab does nothing, then I'd suspect that maybe the Terminal HWND itself doesn't even have focus, and something else is the forground window. Maybe there's something in your profile.ps1 that's like, shelling out to WSL or something

Nothing in my PS profile, it's completely empty.
Long shot, but I also tried stopping a few apps that were running in background (things like AltDrag, AutoHotkey scripts, X server and several others), but unfortunately it didn't help.

I WONDER.
I wonder if this is another facet of #13589. Like, if the WS_TOOLWINDOW created by conpty becomes the foreground window for some reason? It absolutely never should, it's not visible but... clearly there's something weird happening. Maybe this is a clue as to why on Windows 10 the taskbar seems to think that it should restore the hidden window first. Maybe that's why we can't repro this either, we're checking on Windows 11. Hmm.

I have similar issue, but only using command prompt in terminal.
Does not get focus. Need to click to allow typing

I'm experiencing a similar issue too, no matter if I use powershell, cmd or WSL. The window does not accept input and is not reacting to other window manager shortcuts like Win-Down/Win-Up to minimize/maximize the window. Alt-Space opens a context menu at the top-left of the active screen, if that's of any help. I have tried with and without Powertoys and the behavior is the same for me.
I have also identified 3 ways to restore the focus to the terminal window:

Click inside with the mouse.
Pin the terminal to the taskbar and use Win-Number to minimize/restore the window. Restoring the window focuses it.
Try to close the window with Alt-F4. For some reason the window refocuses (it does not close) and then works as expected.

I see the exact behavior @enlavin reported, including the 3 ways to restore focus. It's pretty odd that alt-F4 doesn't close the app but does give my keyboard focus in the open tab. It seems like some other executable is getting focus and alt-F4 kills that executable and that sets focus to Terminal.
I am using Windows 10: 19044.1826
Windows Terminal Version: 1.14.1962.0
My default profile is Command Prompt

I have been having the same issue for a while now. My default terminal is WSL (Ubuntu), but I see the same occur with Powershell and Command Prompt.
New windows and tabs have no focus before mouse click. After the mouse click I can alt+tab between that window and other applications with focus acting as expected. Creating a new tab on the now focused window will return the window to its unfocused state and require a further mouse click to regain it.
The only functions that seem to work on the new window (before focusing with a mouse click) are alt+f4 and minimising the window with win+down.
Weirdly minimising the window with win+down then using alt+tab to open again gives the window focus again. New tabs in this window will work also. I may edit my terminal hotkey to do this for me in the meantime.

I have the problem on Windows 10 that opening a new terminal won't focus the terminal.
But I also noticed the following that I though might be helpful:
using AutoHotkey's Window Spy  when launching a new windows terminal instance I see it reporting that focus is on:
ahk_class PseudoConsoleWindow
ahk_exe OpenConsole.exe

So If I create a hotkey like this:
#t::
Run, wt.exe
WinWait, ahk_class PseudoConsoleWindow
WinClose, ahk_class PseudoConsoleWindow
Return

I can use Win + t to launch windows terminal and I can directly start typing as focus is correctly in the terminal because the PseudoConsoleWindow was closed.

🐉 HERE BE DRAGONS 🐉
I wouldn't do the above post(s) and close the PseudoConsoleWindow. That might just work for now as a workaround for this bug, but could lead to all sorts of weird behavior in the future. It might lead to crashes, or APIs not working right. I know in the past mingw has taken a dependency on that HWND's existence.
As much as it might seem like a viable workaround now, I'd much rather just fix the root cause, than have people try and close that window. I'm gonna collapse comments suggesting to do that for this reason. I don't know why yet the PseudoConsoleWindow is showing up as something that can steal focus (and even be closed in the first place!), but don't go closing it.

Having this same problem on one computer, not on another.
v1.15.2524.0
Consistently works on my personal computer, Windows 10 latest patches.
Consistently does not work on the work computer, managed Windows 10.
The normal Windows keys to resize/move the main Terminal app do not work until I click it with the mouse.
New Terminal windows, tabs, and panes opened within Terminal always need to be manually focused and its driving me nuts :)

I have a similar problem on Windows 10 and Windows Terminal Version: 1.15.2874.0
When I open a new terminal window, the caret does not blink and it does not respond to keyboard input.
It's not possible to open new tabs via hotkeys or to use the windows button to minimize/maximize the terminal window.
CTRL+TAB to focus on the window does not help.
The problem can be fixed by mouse-clicking on the terminal window or by pressing the ALT+F4 hotkey. (The caret starts blinking and hotkeys work).

Same problem with v1.15.2524.0

Lawds I can't repro this. We've got piles of reports, so this is definitely a real bug, but I can't get it to happen with any regularity.
Maybe it has something to do with DPI scaling?
Maybe there's something I can script up to insert in the powershell startup, to debug this? Theoretically, I can't have y'all click on the window to run commands, cause that would manually focus it (destroying the bad state we're curious about). But maybe there's something we can gather at the time the tab is created, automatically?

Wait is WSL installed and running when this repros? Maybe this is the WSLg thing, in secret? Does this happen every time the terminal launches? Maybe it's not the conpty window that's stealing foreground. How to check...

happens everytime when I launch terminal.
I do have WSL installed

Opening any other shell also does not get focus until clicked

Alright, a friend on the input team has an idea. For the folks that are hitting this consistently, we've got an idea how to debug. For this, you'll need InputCore.wprp from: https://gist.github.com/zadjii-msft/b67cc8946202593725f7ada64c6cb0c1

Grab that file and save it somewhere.
Open a conhost window (conhost.exe from the run dialog should work). (This might need to be run as admin, I forget)
In that window, runwpr -start path\to\InputCore.wprp

Open the terminal. Start typing. Obviously, the input won't go into the Terminal window, but the trace should capture who is getting it.
Switch back to the conhost window, and runwpr -stop input_trace.etl

Share that input_trace.etl file here.

This is basically a specific Feedback Hub trace, but without all the extra steps. I'll pass those along to @ekoschik, and hopefully we can get to the bottom of what's going on here.

6. Share that input_trace.etl file here.

input_trace.zip

input_trace.zip
There you go, when opening a WSL window.

Hokay, now I'm maybe asking too much here. Would anyone who's reproing this consistently be willing to check out the Terminal code, build main (just to validate that the issue is still happening on a dev build), then check out dev/migrie/b/13388-experiments-0, and see if the issue persists? Apparently, there's definitely a WM_ACTIVATE in the trace, on the hidden window (which should absolutely never really get brought to the FG).
The theory is that MA_NOACTIVATEANDEAT should prevent that? Again, I can't seem to repro the issue myself, which is why I'm asking for a little help here ☺

Unfortunately I can't seem to get it to even build on my machine currently so it's going to be up to @lbise from the look of it

Looks like I can only reproduce at work and I will be off next week so it will have to wait a bit.

Have you tried that already? ;)

You know, I actually have. This didn't repro on my 19041 laptop, my Win10 VM, my 22000 VM, nor my 25249 PC. Hence why I'm looking for some help.

That's what I thought, but it was worth trying anyway...
I am hitting this all the time now, but I am not able to build it on this PC. I will check on another one if I face the same and try it there.

Alright I'm trying something new:
Dev Build
That should have a CascadiaPackage .msix that will install a Dev build of the Terminal. You should be able to launch the dev version of the Terminal just like the stable version, but with a green DEV logo.
Can folks try that out? (I haven't tried sharing a build like this yet so we might have some technical difficulties)

Got the dev build installed (I quite like the green dev label), unfortunately doesn't resolve the issue. Terminal still doesn't get focus on launch, or when opening a new tab.

Not sure if this matters, but I thought I may share one more observation: it happens that when I start Terminal (i.e. new and first instance) it is already visible as icon on the taskbar, visible in the Alt-Tab list, but window itself is not visible yet. Initially I thought it was my computer lagging or so, but now I think it could have been that this first "invisible" window is up, and the actual terminal is yet to start (due to a lagging PC possibly).
Another idea to check is to install one of the older Terminal releases on a recent Windows 10/11 VM - this may help to determine if there was some change in the Terminal code itself, or maybe some Windows related patch changed its behaviour. Just a thought...

Hokay, now I'm maybe asking too much here. Would anyone who's reproing this consistently be willing to check out the Terminal code, build main (just to validate that the issue is still happening on a dev build), then check out dev/migrie/b/13388-experiments-0, and see if the issue persists?

Do you still need someone to do this, @zadjii-msft?

@lousyd sounds like @spootle tried the release I built manually, and that didn't seem to fix it.
We'll need to come up with some other hypothesis 😕

Another idea to check is to install one of the older Terminal releases on a recent Windows 10/11 VM - this may help to determine if there was some change in the Terminal code itself, or maybe some Windows related patch changed its behaviour. Just a thought...

I suspect it's some Windows related patch too.
I came to this train of thought because I was facing this almost consistently past few months. This behavior annoyed me to point that I developed a habit of clicking terminal after the first seconds.
Oddly, I haven't faced the issue in past few weeks. I'm on Microsoft Windows 10.0.22621 now. Not sure if was fixed in 22H2.

Windows Terminal
Version: 1.15.2874.0
Windows 10 Enterprise
21H2
19044.2251
I started having the issue with Opening New Tabs/Windows and I cannot type in them.
I need to use the mouse and click in the pane to focus.
This had worked OK for years.
I did install a round of Windows updates last week and now Windows Terminal focus is broken.

I'm also having this problem.
Specifically after opening wt (defaults to (old) "Command Prompt") or any new tab (using any shell) I can see that in the first few milliseconds the new window (or tab) has focus and then loses it. This is visible since I have some GUI setting that highlights the focussed window with a colored border.
I could not run wpr as suggested above. It returns
Failed to enable the policy to profile system performance. Profile Id: Core.Verbose.Memory Error code: 0xc5585011 Failed to enable the policy to profile system performance.
This happens both when conhost is run normally or as administrator. This is a company laptop that is greatly locked down, but I do have admin rights (though I have to fill in a form that pops-up every time I do something like this, before it starts the as-admin-process). For that reason, I'm not even going to try to install the dev version, sorry.
My little machine, PPC15491, is a Windows 10 Enterprise build 10.0.19044
Windows Terminal is the 1.15.2874.0 version
Patches:
C:\Users\jvdboss1\Downloads>wmic qfe list Caption                                     CSName    Description      FixComments  HotFixID   InstallDate  InstalledBy          InstalledOn  Name  ServicePackInEffect  Status http://support.microsoft.com/?kbid=5020613  PPC15491  Update                        KB5020613               NT AUTHORITY\SYSTEM  11/16/2022 https://support.microsoft.com/help/5003791  PPC15491  Update                        KB5003791                                    10/6/2021 https://support.microsoft.com/help/5012170  PPC15491  Security Update               KB5012170               NT AUTHORITY\SYSTEM  10/11/2022 https://support.microsoft.com/help/5019959  PPC15491  Security Update               KB5019959               NT AUTHORITY\SYSTEM  11/17/2022                                             PPC15491  Security Update               KB5014032               NT AUTHORITY\SYSTEM  6/24/2022                                             PPC15491  Update                        KB5014035               NT AUTHORITY\SYSTEM  6/24/2022                                             PPC15491  Update                        KB5016705               NT AUTHORITY\SYSTEM  10/11/2022                                             PPC15491  Update                        KB5018506               NT AUTHORITY\SYSTEM  11/16/2022                                             PPC15491  Security Update               KB5005699                                    10/6/2021

I have installed recent updates today, unfortunately no change. I am running Win 10 21H2.
Security Update  KB5021233     NT AUTHORITY\SYSTEM  2022-12-14
Update           KB5020372     NT AUTHORITY\SYSTEM  2022-12-14
Update           KB5020872     NT AUTHORITY\SYSTEM  2022-12-14

It won't be of any help in fixing this issue but I have been using Windows Terminal for more than a year now, and I always had have this terminal focusing issue. Saying so, I don't thing it's related to the past windows updates. Lots of thank yous to everybody trying to fix this issue, it's very appreciated 🥇

I have just received Terminal Preview update to the 1.16.3463.0 version and it seems there is no more focus issue! I will confirm over the next couple of days.

I have just received Terminal Preview update to the 1.16.3463.0 version and it seems there is no more focus issue! I will confirm over the next couple of days.

👀
I honestly don't think there's anything in that latest 1.16 patch that should have fixed this...

Thanks for the tip on the Preview build.
After installing it unexpectedly fixed my Stable build 1.15.3456.0.
I can split terminal panes and open new tabs and focus is correctly following the new pane. Will keep testing...

if #14196 fixed this I'll literally venmo Dustin a beer, cause we've had NO leads for the longest time.
Though, I'd reckon it'd be something that merged after https://github.com/microsoft/terminal/issues/13388#issuecomment-1322337109

@tomasorti You wanna try out https://github.com/microsoft/terminal/releases/tag/v1.15.3465.0? I have literally no reason to suspect that fixes it, but other people have had success?

It seems to work with that version, thank you.
Hope it does not break other stuff...

Thanks for the tip on the Preview build. After installing it unexpectedly fixed my Stable build 1.15.3456.0. I can split terminal panes and open new tabs and focus is correctly following the new pane. Will keep testing...

Unfortunately, this update causes other issues.
Steps:
open an app such as Microsoft Edge or OneNote
open Windows Terminal 1.15.3456.0
select OneNote, start entering text
randomly, the Windows Terminal opens up and the text input is now directed to terminal instead of OneNote

After installing the dev build above...
On launch the new window does not receive focus, but after clicking once to bring it to the foreground newly created tabs do focus correctly.  It doesn't persist though, sometimes switching away and then ALT+TAB to return doesn't return focus to it, but once clicking it works correctly again.
Interestingly I observe the same behaviour in the main Windows Terminal whilst the Dev Windows Terminal is running - new tabs open correctly and it generally works much better.  When Dev Windows Terminal is closed the old behaviour returns.
Hope that's useful to your fault finding.

Hi, I have the following update to my observations above:

it takes this issue 35 seconds to materialize
when focus switch occurs, the new window handle seems to belong to the shell process that was started in the new tab

I have used this quick and dirty script below to get that info - I am not sure if this is a valid troubleshooting, though. I have started in in the Windows PowerShell session running in one of the Windows Terminal tabs. Changing the profile started by the wt new-profile -p "profile" command makes this new invisible window to belong to the respective shell process.
I hope this helps.
try {
	Add-Type @"
using System;
using System.Runtime.InteropServices;
public class Tricks {
    [DllImport("user32.dll")]
    public static extern IntPtr GetForegroundWindow();
}
"@
} catch {
	Write-Host "Add-Type #1 exception"
}

try {
	$user32 = Add-Type -MemberDefinition @'
[DllImport("user32.dll", SetLastError=true)]
public static extern uint GetWindowThreadProcessId(IntPtr hWnd, out uint lpdwProcessId);
'@ -PassThru -Name user32Func
} catch {
	Write-Host "Add-Type #2 exception"
}

function log($txt) {
	$ts = Get-Date
	Write-Host "[$ts] $txt"
}

$stopwatch = [System.Diagnostics.Stopwatch]::new()

log "Starting WT..."
wt new-tab -p "PowerShell"
$stopwatch.Start()
log "...done"

# Get current (wt) window ID
$current_wt_win_handle = $([tricks]::GetForegroundWindow())
log "Current WT handle: $current_wt_win_handle"
$wt_proc = 0
$wt_thread_id = $user32::GetWindowThreadProcessId($current_wt_win_handle, [ref]$wt_proc)

log "Current WT process: $wt_proc / $wt_thread_id"

log "Wating for focus issue to occur."
while (1) {
	$new_win_handle = $([tricks]::GetForegroundWindow())
	if ($new_win_handle -ne $current_wt_win_handle) {
		$stopwatch.Stop()
		log "Got new handle ($new_win_handle) after $($stopwatch.Elapsed)"
		$new_proc = 0
		$new_thread_id = $user32::GetWindowThreadProcessId($new_win_handle, [ref]$new_proc)
		$new_proc_name = (Get-Process -Id $new_proc).Name
		log "New process: PID: $new_proc / TID: $new_thread_id / Name: $new_proc_name"
		exit
	}
	Start-Sleep .1
}

Yet another update:

time required for the focus issue to occur is not always ~30 seconds. Today it was ~20 for me.
if I open a new tab, then open yet another new tab and close it, issue will not occur.

I'm experiencing a similar issue as this but on Microsoft Edge, in addition to Windows Terminal. Quickly alt-tab from an app to edge, the edge title lights up but then no keyboard button works i have to click inside to use it.

Hi @zadjii-msft
do you have any new idea of how to approach this issue? Any hope to have it resolved? 🥺
Regards,
T

Nope, not yet. Just getting back from the holidays for the last couple weeks. I'll probably needs some help from my resident User32 expert colleague, who I think is still out this week. The MA_NOACTIVATEANDEAT thing didn't work, so it's back to the drawing board.

New year, new shot in the dark to fix it. Could I have some folks who are still hitting this bug try the following build?
>> Get the .msix here <<
That should have a CascadiaPackage .msix that will install a Dev build of the Terminal. You should be able to launch the dev version of the Terminal just like the stable version, but with a green DEV logo.
Can folks try that out?

Can folks try that out?

This build appears to have resolved it for me in initial testing, with a completely unrelated side effect of the dark mode for settings having the light mode color background rendering it completely unreadable (but it at least appears to resolve this actual issue as far as I can see so far)

Hmm. That's probably a regression from #14567 oh god yea I definitely broke that. But that's totally unrelated (thankfully)!
That's great to hear. I'll give folks a bit longer to see if there's any other feedback. If I get any more confirmation that it seems to work, I'll probably just file a PR to put that in 1.17 for later this month.

I have this issue too.

@winni2k you mean the same as @spootle reported? What about the original (focus) issue - did it get fixed for you?

I tried to install .msix file, but it is unsigned. I'll have to wait for others to do the testing, sorry.

Oh derp that makes sense, I think I used the PR build pipeline instead of the Release build 😅 I can kick one of those off.

@zadjii-msft I am afraid a severe security threat has been introduced with this new update. Indeed, the focus is not lost anymore. However, the terminal now actively steals the focus from other applications ~30 seconds after the start if it is not active. To reproduce it: start a terminal, then switch to another app, and approximately 30 seconds after the terminal was launched it will pop up and get the focus.
Imagine a scenario where you type something in a notepad (pressing Enter occasionally) and not looking at the monitor. What can happen is that you might execute a command without being aware of that, which is very dangerous. I would rather prefer to lose the focus from terminal than terminal actively stealing the focus from other apps.

Hmm. That does seem to corroborate earlier reports that the Terminal loses focus about 30s after launching the tab. The change in that build is intended to yeet focus from the hidden window backing each tab, to the main Terminal HWND whenever the hidden window gets activated. The fact that it's getting activated at all, let alone 30s after launching the tab, that's what we don't understand. It's an invisible window. It's got WS_EX_NOACTIVATE. It should never be activated in the first place.
Back to the drawing board.

Interestingly I can't replicate this stolen focus report, I've been using that latest dev build since installing it and it hasn't stolen focus once, it's behaved exactly as I would expect any other window to. In fact I'm even typing this slowly after freshly starting the terminal just to see if it steals any of this text, and it hasn't taken any of it.
For @winni2k, you can install the unsigned package by extracting the .msix to a folder and using Add-AppxPackage -Register .\AppxManifest.xml in powershell

Interestingly I can't replicate this stolen focus report

It's just the darndest thing. We're a tad worried that there's something installed / running that's affecting the timing here. Something like some accessibility tool, or antivirus, or autohotkey, I dunno those are just usual suspects.
My next theory is to yeet activation back at whoever just lost activation. Theoretically, that would toss it back to whoever is actually in the FG. Theoretically.

My next theory is to yeet activation back at whoever just lost activation.

This is a dangerous game to play, and I don't recommend we do that! Can the pseudoconsole window simply reject activation and let the system do what it would otherwise? Can the window be made nonactivatable?

Can the pseudoconsole window simply reject activation and let the system do what it would otherwise? Can the window be made nonactivatable?

By all accounts, setting our window as WS_EX_NOACTIVATE should have done that. I'm pretty sure there's no way to say "no thanks, I don't want to be activated" once we get that message.

Could this be related to Docker For Windows Desktop ? I see in procmon it spams launching a wsl shell every few seconds for stupid reasons which causes all kinds of trouble (Makes the task bar go up and down by itself, auto hide mode), and prevents my monitors from sleeping.

YES IT COULD BE

I am deliberately running a much older version of Docker Desktop (4.2.0) due to other issues I have had in the past with upgrading it, if that helps narrow down why mine isn't stealing focus...

Alternatively, it could be because some CLI process it calling ActivateWindow(GetConsoleWindow()), though, that would probably be more obviously related to whatever's running in the console when the bug occurs.
I honestly have no idea if the Docker thing is necessarily related. I know there's been a lot of issues in the past with WSLg starting up and stealing focus. Docker does have some WSL distros that they use behind the scenes, so maybe that's complicating things.
That however wouldn't explain why our "manually focus the Terminal when our hidden hwnd gets WM_ACTIVATE'd" seems to steal focus after some time.

Interesting late friday notes:

function steal-fg {
  $console = [Native]::GetConsoleWindow()
  Write-Host ("Console`t`t{0:x}`n" -f $console)
  Write-Host ("SAY GOODBYE TO YOUR FOCUS`n")
  [Native]::SetForegroundWindow($console);
}

function import-native()
{
  $NativeFunctions=@"
  using System;
  using System.Runtime.InteropServices;
  public class Native {
      [DllImport("kernel32.dll", SetLastError = true)]
      public static extern IntPtr GetConsoleWindow();
      [DllImport("user32.dll")]
      public static extern bool SetForegroundWindow(IntPtr hWnd);
  }
"@

  Add-Type -TypeDefinition $NativeFunctions
}

pwsh -command { import-native; steal-fg; } will then steal the focus. Presumably, in the same way. I don't think there's anything we can do about that, yikes.

Another thought - we might be able to rule out or finger WSLg this by temporarily disabling WSLg: Configuration setting for .wslconfig. Though, the notes there state that setting only works on Windows 11, and it seems like most folks are encountering this on Windows 10. I dunno for sure if that * is a lie or not.
I might start next week looking through here: https://github.com/docker/for-win/issues?q=is%3Aissue+console+window. That sure does feel like a dead end though.
That's all I've got for this weekend.

Another thought - we might be able to rule out or finger WSLg this by temporarily disabling WSLg

I had this issue on Windows 10 provided by my employer with old builtin WSL (no WSLg). I have been able to install WSL from the store just recently so I don't think WSLg is related at all.

The issue only happens once on first usage after reboot for me. Once I face the loss of focus issue, it doesn't lose focus on any new terminal window till next reboot of my PC.
I noted this multiple times so I'm about 80% sure.

I confirm this has been hapening to me before I have installed WSL from the
store. Also, it does not affect only WSL sessions; PowerShell or cmd are
also affected. I do have autohotkey installed (as someone suggested
earlier) - I will stop all running AHK scripts and check that again
(although I think I have already checked that in the past...) The idea of
some specific AV software may also be correct I'm afraid...
Anyway, it's good to see some traction here after a while!
sob., 14 sty 2023, 06:49 użytkownik Numan Zaheer Ahmed <
@.***> napisał:

The issue only happens once on first usage after reboot for me. Once I
face the loss of focus issue, it doesn't lose focus on any new terminal
window till next reboot of my PC.
I noted this multiple times so I'm about 80% sure.
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/terminal/issues/13388#issuecomment-1382668748,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AL5LUZ64SC44T3EU27LM3JLWSI45DANCNFSM5Z6SZ2FQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

With no AHK scripts running (and also with PowerToys stopped - it's Run component has a plugin for WT) - no luck.

Another thought - we might be able to rule out or finger WSLg this by temporarily disabling WSLg: Configuration setting for .wslconfig. Though, the notes there state that setting only works on Windows 11, and it seems like most folks are encountering this on Windows 10. I dunno for sure if that * is a lie or not.

WSLg works for recent updates of Windows 10 as well. I have just disabled it but it did not help. Anyway, I regularly run WSLv1 distro only and v2 is rarely in use, but the focus issue is constantly present.
Why is it considered it has anything to do with WSL? I face this problem even if the only opened tabs in WT are PowerShell and newly started are e.g. CMD or PowerShell (with wsl completely stopped via wsl --shutdown)

Why is it considered it has anything to do with WSL?

Eh, the Docker comment before had me drilled in on something that wasn't relevant. Docker leverages WSL distros in unusual ways to back some of its containers. I thought there was a chance there was a bug in the interaction between those distros and the WSLg bug that steals focus on boot.
Anywho, since folks are seeing this entirely without WSL, then that's a dead end.
Instead, we might want to drill in on whatever's trying to SetForegroundWindow the console window. That's obviously not gonna work. Though, it's like... if that's what some script was trying to do, then in conhost, you'd see the Console window pop up unexpectedly. I still wanna say this is something weird that the OS is doing with the pseudo window on launch. Maybe I just need to add gratuitous tracing to try and get a collection of window messages (and timing) for my User32 friends to take a look at.

Instead, we might want to drill in on whatever's trying to SetForegroundWindow the console window.

Since a few people here reported the problem on company's PCs - can it be that it is some antivirus or other anti-malware software trying to scan/analyse the console process with hidden window for potential threats? Is there any way to track it further down?

wake up babe, new random shot in the dark to try out just dropped. Could I have some folks who are still hitting this bug try the following build?
>> Get the .msix here <<
That should have a CascadiaPackage .msix that will install a Dev build of the Terminal. You should be able to launch the dev version of the Terminal just like the stable version, but with a green DEV logo. It might be unsigned - sorry about that! I don't think I know how to release-sign a dev build like this. You may need to enable Developer Mode to let the OS install unsigned packages.
Can folks try that out?
(this is commit 68d854011, which is "try to set the owner HWND immediately as the conpty is created")

@zadjii-msft unfortunately for me this build has reverted the focus behaviour back to the original issue, opening a new window or tab doesn't set focus to the terminal at all

Welp, then we'll have to try Plan D. The D stands for "I Dunno what we're going to try next".
(thanks everyone for bearing with my ever increasing frustration with this one. I'm attempting to use humor as a defense mechanism)

unfortunately for me this build has reverted the focus behaviour back to the original issue, opening a new window or tab doesn't set focus to the terminal at all

That at least was much less annoying as compared to the currently observed behaviour.
I know it may sound crazy, but is it worth trying - with this immediate focus loss - to forcefully set focus back to the terminal after a fraction of the second? Not a solution definitely, but maybe some workaround that may make it more usable and give more time to actually fix it.
The other option that comes on my mind is to try installing WT version older than 1.14.1451.0 (which is mentioned in this bug report in the initial post) and see if that behaves normally? This way we could rule out other things, theoretically...
I wish I could try that myself but with limited privileges I have on my PC I can only install what gets officially released via Store.

I know it may sound crazy, but is it worth trying - with this immediate focus loss - to forcefully set focus back to the terminal after a fraction of the second? Not a solution definitely, but maybe some workaround that may make it more usable and give more time to actually fix it.

You'll note that's basically what I tried in https://github.com/microsoft/terminal/issues/13388#issuecomment-1379117011 (which was https://github.com/microsoft/terminal/commit/7da382c948265d64e600a75f9c7fd49bfe38141a). Basically, whenever the pseudo window got activated, I'd re-activate the Terminal window.
The curious thing here is this mysterious 20-30s delay. That pseudo window should be created basically as soon as the tab starts. There shouldn't be any reason for that window to be activated by the system, unless it's being activated by some commandline script / exe.
Now, if the focus gets stolen after some delay, while the tab is just sitting idle (just sitting at a powershell / cmd prompt), then that makes me thing one of these things is happening:

The OS substantially delayed the creation of that pseudo window.

I'm not even sure I trust this theory. Usually if an app creates a window, but that app isn't the FG window, then windows just blinks the taskbar icon at you. It doesn't typically pop that new window into the foreground AND activate it. That's nonsense. It'll only grant foreground to the new window if the thing creating the window currently had foreground.

Some other thing created a commandline process via the "default terminal" functionality, and that tab instantly closed, but not before the pseudo window had a chance to appear and try to activate.

this would only apply to Windows 11, with a particular set of settings, and seems... unlikely. I suppose that could be diagnosed with a closeOnExit: never in the settings, but I'm doubting this

There's some other thing stealing focus

this seems to be ruled out by https://github.com/microsoft/terminal/issues/13388#issuecomment-1357415961. That comment suggests the commandline app got focused, which makes sense - the system treats that psuedo window as the HWND of {your console application}.

It's seemingly none of those, so what is it
I think I'm gonna try a variation on attempt-001, but making sure the active window (which is losing activation) is in fact, the Terminal's window. That should mitigate https://github.com/microsoft/terminal/issues/13388#issuecomment-1382027489, where some other app is active when the pseudo hwnd gets activated, and we end up taking foreground from it.

Thanks for explaining it!

Now, if the focus gets stolen after some delay, while the tab is just sitting idle (just sitting at a powershell / cmd prompt) [...]

Maybe it is just me misinterpreting what you wrote, but this happens not only if the tab is idle - if I am typing into the tab, the focus would be lost as well.
There is one more thing I have noticed and that is quite consistent (regardless of both tabs use the same shell or not):

Start new tab (let's call it A).
Right after it starts, start yet another one (this one is B).
Close tab B.
Focus will NOT be lost.

But when you close tab A instead of B in step 3 above, it would. So it seems this hidden window gets only activated for the most recently started tab/shell.

Found the culprit I think:
C:\Program Files\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux_<IP_ADDRESS>_x64__8wekyb3d8bbwe\msrdc.exe

Tool used is https://github.com/JocysCom/FocusLogger.

@Anutrix I think we have already ruled out WSLg. Also, this problem occurs even if there is no WSL running at all. And the application that "gets" the focus when it is stolen from Windows Terminal is the shell process of the most recently started Windows Terminal tab and not msrdc.exe

@Anutrix I think we have already ruled out WSLg. Also, this problem occurs even if there is no WSL running at all. And the application that "gets" the focus when it is stolen from Windows Terminal is the shell process of the most recently started Windows Terminal tab and not msrdc.exe

I have never lost focus when WSL wasn't running. So it might be a different bug.
And I have 100% lost focus when WSL was started while msrdc.exe has already not started.

Could it be Discord ? I see it flashes the taskbar icon a lot and is focus-steal happy.

Could it be Discord ? I see it flashes the taskbar icon a lot and is focus-steal happy especially when trying to notify for new messages.

Unlikely. I have this problem on a machine without discord, and not on a machine with discord. (unless the guilty part is a component or something that discord is sharing with something I have installed)

I just tried the focus monitoring tool shared by @Anutrix and these are my results:

Initially pwsh is getting the focus instead of WindowsTerminal, so it's not accepting any of my keypresses. After about 8 seconds pwsh grabs the focus I press Alt-F4 and then WindowsTerminal is finally able to get the focus and I can start typing normally.

Ah shoot. Okay, so now we've got some folks with this issue due to WSLg, and some without it. Shoot. That's gonna make reparsing this whole thread.... challenging. I might need to create a separate table with all the folks experiencing this, that have confirmed they don't have WSL installed. Like, at this point, I might need to be as nuclear as that to rule it out.
The MSCTFIME UI invokes are also... interesting to me. The IME totally could be something that does w e i r d things. Like, it's not here in that trace above, but.... maybe that's the thing trying to smuggle focus from the Terminal to the phwnd.

To add a bit more info to my previous comment:

this is a company issued laptop with Microsoft Windows 10 Enterprise version 10.0.19044 N/A Build 19044
Terminal build is 1.15.3465.0 (because of ☝ I cannot test your unsigned builds, sorry)
I have WSL installed, but I was shut down for the tests
I do use a English + Chinese IME, which was in English at the time of my tests

I do use a English + Chinese IME

@migue-pki Just for my own notes, which one & version? Literally anything could be a lead at this point. This thread might be tracking 4 different root causes for all I know.

The IME is just the one that comes with Windows 10, no additional third parties packages as far as I know:

I'm gonna stash some quick notes before I hit the road for the weekend:

I basically have no leads left on this. I cannot get it to repro on my (real old) home Windows 10 PC, which provides no end of frustration.
My only remaining theory is that there's some third-party software that's causing the hidden window to get erroneously activated, but I have no good ideas for how to identify that.

Theoretically, if folks filed feedback using the Feedback Hub (and share the aka.ms link here), I might get a list of your installed apps. I could possibly use that to find whatever the intersection is, and research those apps to find a repro.

Once 1.17 is out (soonTM) I'm gonna whip up a compatibility switch for disabling this hidden window. It'll basically disable the fixes for #2988, so there'll be a lot of scenarios where apps were using GetConsoleWindow() that will break in the Terminal again. But I'm under the impression that the pain of this bug is a lot worse than the small population of apps that were using that API in the first place.
We're gonna leave this open, because we do want to get to the bottom of this. But at least for the time being, we're gonna lean on that opt-out.

Sorry, I wish it was better news.

Not sure if this will help anyone, but in my case I was running a python-script I had scheduled to run before the terminal-launch with another script that launches it without showing a console window pop up.
That's what was stealing my focus (inconsistently), and as far as I can tell only on first launch of WT via shortcut [second window opened via shortcut is focused].
<#+2::
Run, C:\bat\NoScript.vbs python "C:\Users\chris\Pictures\Windows Terminal Background Pictures\python-script.py"
Run, C:\Users\chris\AppData\Local\Microsoft\WindowsApps\wt.exe -p "Ubuntu_new_Session"
return

removing NoScript.vbs fixed the issue for me.
NoScript.vbs:
    ReDim arr(WScript.Arguments.Count-1)
    For i = 0 To WScript.Arguments.Count-1
        Arg = WScript.Arguments(i)
        If InStr(Arg, " ") > 0 Then Arg = """" & Arg & """"
      arr(i) = Arg
    Next

    RunCmd = Join(arr)
    CreateObject("Wscript.Shell").Run RunCmd, 0, True
End If

P.S: The python script renames the image files in my folder from i.png to i+1.png (with a modulo by n), where i = [0..n]) and I choose 0.png as my background image in the wt settings so I have e new background every time I launch. Would be a cool feature if we could just select a folder for background image and WT selects the image randomly from there.

My only remaining theory is that there's some third-party software that's causing the hidden window to get erroneously activated, but I have no good ideas for how to identify that.

I still have zero focus stealing issues with attempt-1 (using as daily driver since), so I agree that others most likely have something installed that's doing this that I don't. Unfortunately my corporate group policy apparently blocks me from submitting feedback through feedback hub, is there any other way to manually get the list that would have generated?

I think it may be that all these attempt-n were never tested enough by this community here. And e.g. in my case it was because I am unable to install it if it does not come from the store (or is not signed, whatever).
@zadjii-msft - with the attempt-1 resulting in some positive feedback, would it be possible to include it in the next Terminal Preview release so that it can be easier deployed and tested?

I'm also seeing this (focus stolen after 5 or 10 seconds, only on the first WSL start from shutdown state) on a work computer (group policy, etc):
WSL version: <IP_ADDRESS>
Kernel version: <IP_ADDRESS>
WSLg version: 1.0.47
MSRDC version: 1.2.3575
Direct3D version: 1.606.4
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19043.2364

caused (like the others mentioned) by msrdc.exe.
Process Monitor shows a ton of activity: registry access, loading DLLs, opening files, starting new threads. The main thread created has Command line msrdc.exe /v:9740E94F-E8E4-425C-B405-17FC49E1DC02 /hvsocketserviceid:4275F880-FACB-11E6-BD58-64006A7986D3 /silent /wslg /plugin:WSLDVC_PACKAGE /wslgsharedmemorypath:WSL\9740E94F-E8E4-425C-B405-17FC49E1DC02\wslg "C:\Program Files\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux_<IP_ADDRESS>_x64__8wekyb3d8bbwe\wslg.rdp" (although if I add the .wslconfig line for disabling wslg, I still have focus stolen).
Only other notable details I can imagine: using AHK, proxy, a handful of network mounts, some Novell management software, running rkhunter in the background as part of my startup .rc (although that has been in-place for over a year while the focus stealing started a few weeks or months ago), and I just recently switched to the Store-based WSL. This does not happen with Powershell/cmd.exe---only with WSL (however, the focus stealing also happens in the classic conhost terminal)
I'm not sure what other detail to provide because the procmon capture of msrdc is pretty overwhelming (51,000+ events). Also, it seems this is WSL-related on my machine, so it probably belongs on microsoft/wsl rather than here, but as others mention Powershell is also affected, I can only share my own experience without a strong recommendation.

/idle thought: could it be some flavor of git? When I git commit, then save the file and exit it, focus doesn't return to the Terminal. Maybe it never did. Maybe they're manually activating the console HWND - they've done silly things with the HWND in the past...

I don't think it has anything to do with Git. I have seen it recently on a PC with no Git installed. I am tempted to say it may be caused by some AV or other security application.

Got the same issue (after opening session focus is on the Tab itself, not on the command line input, so have to click)
But got it only in the recent Preview build and only with sessions in folders/groups.
The same session in the main list (outside of a folder) works well.
All my sessions are SSH ones: "commandline": "ssh somehost"
Any workaround, please?

same issue on windows 10

Wait so I had a totally random other thought about this.
Again, let's not involve WSL at all in this, because of the aforementioned issues with WSLg stealing focus as it boots up. So only test with Command Prompt or PowerShell tabs (and make sure WSL isn't in your profile.ps1)
Does this repro

on the first launch of the Terminal? OR
does it only repro after opening a new tab?

and if it only happens when opening a new tab, HOW are you opening the tab?

The new tab dropdown?
the command palette?
the tab context menu?
A keybinding?

There's been bugs in the past about focus secretly moving somewhere else in the Terminal app itself. Most recently, #15049. That one's specific to nested dropdown entries (which are new in 1.17), but a helpful reminder that we've had these issues before. ESPECIALLY when opening tabs via the new tab dropdown.
I still haven't had any luck repro'ing this. Maybe for the folks who are seeing this, especially after some delay, can you try https://github.com/JocysCom/FocusLogger? That 3p tool looks like it's exactly what we need to root cause who's stealing the focus here.
Adding a flag to disable #2988 is... complicated, especially considering the way it's all plumbed together.

I recently installed Windows Terminal Preview version 1.17.1023 from the Microsoft Store. I proceeded to add some new profiles. I created some where the command line is "%WINDIR%\\System32\\OpenSSH\\ssh.exe user@host". These new profiles launched in new tabs and immediately received focus.
Here's the interesting part: I copied the GUID of one of these profiles to the new newTabMenu section of the settings.json file and put it inside of a folder. When I launched the profile from within the folder the new tab did not receive focus. I reproduced this multiple times. As another test I pressed the tab key after launching the profile from within the folder and the plus sign and down arrow immediately to the right of this new tab became highlighted with a black border around them. This would seem to indicate that after launching a profile from within a folder, the tab title itself is where the focus is rather than within the tab's window/body.
I hope this information can be helpful to someone. I apologize that I did not have time to read through this entire issue to see if this has already been brought up by someone else or if there is another issue with similar information.

On my company laptop, I'm experiencing almost the exact issue @trueuto described here: https://github.com/microsoft/terminal/issues/13388#issuecomment-1354331077
i.e. New tab then focus switched to the shell process after ~30 seconds. No WSL running (though installed).
Some more details and possible culprit in my specific case:

I noticed that the focus switch is always accompanied by a "Thread Exit" operation as shown by procmon.exe.
This thread is created right when the new tab is created in Windows Terminal. (More specifically it's always after the "Process Create" event for OpenConsole.exe and before the "Process Create" event for the shell process (e.g. cmd.exe or pwsh.exe), but I don't know if this is deterministic)
While the suspect thread is running, I looked it up in procexp.exe - its start address is in C:\Program Files\Avecto\Privilege Guard Client\PGHook.dll and with stack like this

ntoskrnl.exe!KeSynchronizeExecution+0x6c56
ntoskrnl.exe!KeWaitForSingleObject+0x1460
ntoskrnl.exe!KeWaitForSingleObject+0x98f
ntoskrnl.exe!KeWaitForSingleObject+0x233
ntoskrnl.exe!RtlFindClearBitsAndSetEx+0xc7d
ntoskrnl.exe!KiCheckForKernelApcDelivery+0x359
ntoskrnl.exe!KeWaitForSingleObject+0x1787
ntoskrnl.exe!KeWaitForSingleObject+0x98f
ntoskrnl.exe!KeDelayExecutionThread+0x122
ntoskrnl.exe!MmProbeAndLockProcessPages+0x245f
ntoskrnl.exe!setjmpex+0x82d5
ntdll.dll!NtDelayExecution+0x14
KERNELBASE.dll!SleepEx+0x9e
PGHook.dll!PGHookFunction+0x406c1
PGHook.dll!PGHookFunction+0x3a4c3
PGHook.dll!PGHookFunction+0x3ab0e
PGHook.dll!PGHookFunction+0x3aa42
PGHook.dll!PGHookFunction+0x73670
KERNEL32.DLL!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21

"Privilege Guard Client" is part of the BeyondTrust privilege management solution that our IT has deployed recently. It seems a very like culprit at least in my case. Will talk to our IT for more details.

WELL THAT LOOKS LIKE A CULPRIT

I also run beyond trust on my machine and have this issue.
On May 25, 2023, "Maxime U. Garcia" @.***> wrote:

I think there's a registry value called "HookExclusions" under an
"Avecto" key. I can't check personally; I reinstalled Windows on my
work computer and the issue is now gone for me… no idea if I had
Avecto on the old installation.

—
Reply to this email directly, view it on GitHub
<https://github.com/microsoft/terminal/issues/13388#issuecomment-
1562983485>, or unsubscribe
<https://github.com/notifications/unsubscribe-
auth/AACKOPQ3IZZ5UIQQN4VJST3XH5SEDANCNFSM5Z6SZ2FQ>.
You are receiving this because you were mentioned.Message ID:
@.***>
--
Sent with HEY https://hey.com/sent

I am still experiencing the issue, and I also have the luck of enjoying "Privilege Guard Client" by Avecto in my company laptop thanks to our IT. HookExclusions does not seem to be not honored, and ManagedHookExclusions is read-only of course.

Funnily enough, if I copy WindowsTerminal.exe with a name in the whitelisted programs list stored in ManagedHookExclusions the focus issue no longer happens to that terminal 🤦

Funnily enough, if I copy WindowsTerminal.exe with a name in the whitelisted programs list stored in ManagedHookExclusions the focus issue no longer happens to that terminal 🤦

Same situation, I can not edit ManagedHookExclusions myself, Is there other solution?

@ilyaradko - what is the Windows version you run? Is it Win10 22H2 already?
It may be good to find out if Win version may be the common denominator here too.

@trueuto, yes, Win10 22H2, Terminal version 1.16.10261.0.

Another report of repro'ing the issue and we also have Avecto BeyondTrust Privilege Management deployed.

I also have BeyondTrust Privilege Management on the work laptop where I experience this. Plus I work at the same company as @praimmugen so it's very likely they had the same software installed at the time of opening the original issue.

I don't have BeyondTrust Privilege Management installed, but still affected by focus issue

@zoulja do you have another type of privilege management software on your computer?  I don't have BeyondTrust, but I have CyberArk and I get the same behavior when creating new tabs.

With all signs of the issue being caused by BeyondTrust (but possibly by some other software too), @zadjii-msft - is there anything you could make to do things you do differently? I know it is not your "fault", but I hardly can imagine these companies making any exceptions or amendments to their software just to make WT users happy...

@zoulja do you have another type of privilege management software on your computer? I don't have BeyondTrust, but I have CyberArk and I get the same behavior when creating new tabs.

Nope, this is my home laptop, without any corporate software, just default Win11 setup @saenzfco

I have the issue on my corporate laptop that uses BeyondTrust.

It happens for me on my personal windows 10 laptop with no corporate sniffing/security software running.
It doesn't seem to even happen with cmd.exe tabs, but it does happen with Ubuntu tabs AFTER I've issued wsl --shutdown elsewhere...  So maybe it's a timing issue related to the slower startup when wsl needs to start up?
I can repro this consistently by running wsl --shutdown and then opening a new Ubuntu tab via keyboard shortcut.  The tab will open and then Terminal visibly loses focus.
I'm running in quake mode, if that helps.

Re-posting from my duplicate issue #15786
Okay, I did some version testing.
Version 1.13 works perfectly. Never loses focus to a hidden window
Version 1.14 loses focus once immediately on startup, but not with new tabs. This is the behaviour described at the start of #13388
Versions 1.15 through 1.18 preview all manifest the behaviour on #15786; every new tab lose focus to a hidden window after about 30 seconds

I rolled back to version v1.13.1143 and can confirm that the issue is absent. Will stick to this version then. Thanks a lot, @ryanmda, for posting your test results!

After v1.13.11431.0 - Stable v1.13 comes:
v1.14.1432.0
v1.14.1451.0 - This ticket's OP.
v1.14.1861.0 - Stable v1.14.
v1.15.186
v1.15.200
v1.15.228
v1.15.252 - Stable v1.15.
Note: Skipped service releases.
Just a list for those who want to test the versions one by one.
If we can get exact versions where each of the issues started maybe we can bisect it to two commits. I don't see any other way forward for this year-old issue.

I mean, I'm 100% certain it's one of the #2988 commits[^1]. Those are the ones that introduced the pseudo-hwnd (that's seemingly getting troubled here). Problem is, that's a pretty major compatibility feature that we definitely can't just revert. And there's not a simple opt-out, as I once thought there might be[^2].
I don't have any ideas as to what we could do to mitigate this. I'd need to get someone to do a kernel trace with PGHook loaded to see exactly what they're calling. I wouldn't think that a 30s Sleep, even at the start of OpenConsole's launch, would affect the path I'm thinking of, but user32 is dark and full of terrors. I'd suspect that this wouldn't apply to "defterm" launches[^3]. Though, if they're hooking OpenConsole.exe, then... wouldn't that just hang all defterm console launches by 30s? That seems... insane.
[^1]: Those commits being:
* #12515,
* #12526,
* #12799,
* #12899,
* #12900
[^2]: I previously thought it'd be possible to just pass a flag to conpty to disable creating the pseudo-hwnd (and revert to the old behavior). There was some reason I thought that would end up being Hard to do, though I can't remember why now.
[^3]: where you launch cmd.exe and that boots into a Terminal window instead of a conhost one. That's available on Windows 11 and newer Windows 10 builds

I thought I'd post that this got fixed for me a few weeks back. I assume
it was a windows update of some kind. I tried to post at the time but
the comments seemed to have been disabled.
On August 2, 2023, "Maxime U. Garcia" @.***> wrote:

I mean, I'm 100% certain it's one of the #2988
https://github.com/microsoft/terminal/issues/2988 commits1 <#user-
content-fn-1-65b1673a71d2428b02f2ef0525829524>. Those are the ones
that introduced the pseudo-hwnd (that's seemingly getting troubled
here). Problem is, that's a pretty major compatibility feature that we
definitely can't just revert. And there's not a simple opt-out, as I
once thought there might be2 <#user-content-fn-2-
65b1673a71d2428b02f2ef0525829524>.
I don't have any ideas as to what we could do to mitigate this. I'd
need to get someone to do a kernel trace with PGHook loaded to see
exactly what they're calling. I wouldn't think that a 30s Sleep, even
at the start of OpenConsole's launch, would affect the path I'm
thinking of, but user32 is dark and full of terrors. I'd suspect that
this wouldn't apply to "defterm" launches3 <#user-content-fn-3-
65b1673a71d2428b02f2ef0525829524>. Though, if they're hooking
OpenConsole.exe, then... wouldn't that just hang all defterm console
launches by 30s? That seems... insane.
Footnotes

Those commits being:

#12515 https://github.com/microsoft/terminal/pull/12515,
#12526 https://github.com/microsoft/terminal/pull/12526,
#12799 https://github.com/microsoft/terminal/pull/12799,
#12899 https://github.com/microsoft/terminal/pull/12899,
#12900 https://github.com/microsoft/terminal/pull/12900

↩ <#user-content-fnref-1-65b1673a71d2428b02f2ef0525829524>

I previously thought it'd be possible to just pass a flag to conpty
to disable creating the pseudo-hwnd (and revert to the old
behavior). There was some reason I thought that would end up being
Hard to do, though I can't remember why now. ↩ <#user-content-
fnref-2-65b1673a71d2428b02f2ef0525829524>

where you launch cmd.exe and that boots into a Terminal window
instead of a conhost one. That's available on Windows 11 and newer
Windows 10 builds
https://github.com/microsoft/terminal/discussions/15505
↩ <#user-content-fnref-3-65b1673a71d2428b02f2ef0525829524>

—
Reply to this email directly, view it on GitHub
<https://github.com/microsoft/terminal/issues/13388#issuecomment-
1662478457>, or unsubscribe
<https://github.com/notifications/unsubscribe-
auth/AACKOPU5QIYOVHXQYKZ3FRTXTJ2DFANCNFSM5Z6SZ2FQ>.
You are receiving this because you were mentioned.Message ID:
@.***>
--
Sent with HEY https://hey.com/sent

I mean, I'm 100% certain it's one of the #2988 commits1. Those are the ones that introduced the pseudo-hwnd (that's seemingly getting troubled here). Problem is, that's a pretty major compatibility feature that we definitely can't just revert. And there's not a simple opt-out, as I once thought there might be2.
I don't have any ideas as to what we could do to mitigate this. I'd need to get someone to do a kernel trace with PGHook loaded to see exactly what they're calling. I wouldn't think that a 30s Sleep, even at the start of OpenConsole's launch, would affect the path I'm thinking of, but user32 is dark and full of terrors. I'd suspect that this wouldn't apply to "defterm" launches3. Though, if they're hooking OpenConsole.exe, then... wouldn't that just hang all defterm console launches by 30s? That seems... insane.

That may be a dead-end, but at some point 1.16.3463.0 release has changed the behaviour: from instant focus loss to a delayed one, by approx. 30 seconds. It was about when I initially thought the issue was completely gone. So, even if 1.16.3463.0 did not fix it, there was some change that seems to have impact on the problem by introducing that delay...

I also see a random focus loss every now and then. 30 seconds send about
right.
On August 17, 2023, "Maxime U. Garcia" @.***> wrote:

I mean, I'm 100% certain it's one of the #2988
https://github.com/microsoft/terminal/issues/2988 commits1 <#user-
content-fn-1-3c35df30e5cea17508632d1c8cee1591>. Those are the ones
that introduced the pseudo-hwnd (that's seemingly getting troubled
here). Problem is, that's a pretty major compatibility feature that
we definitely can't just revert. And there's not a simple opt-out,
as I once thought there might be2 <#user-content-fn-2-
3c35df30e5cea17508632d1c8cee1591>.
I don't have any ideas as to what we could do to mitigate this. I'd
need to get someone to do a kernel trace with PGHook loaded to see
exactly what they're calling. I wouldn't think that a 30s Sleep,
even at the start of OpenConsole's launch, would affect the path I'm
thinking of, but user32 is dark and full of terrors. I'd suspect
that this wouldn't apply to "defterm" launches3 <#user-content-fn-3-
3c35df30e5cea17508632d1c8cee1591>. Though, if they're hooking
OpenConsole.exe, then... wouldn't that just hang all defterm console
launches by 30s? That seems... insane.

That may be a dead-end, but at some point 1.16.3463.0 release has
changed the behaviour: from instant focus loss to a delayed one, by
approx. 30 seconds. It was about when I initially thought the issue
was completely gone. So, even if 1.16.3463.0 did not fix it, there was
some change that seems to have impact on the problem by introducing
that delay...

—
Reply to this email directly, view it on GitHub
<https://github.com/microsoft/terminal/issues/13388#issuecomment-
1681817862>, or unsubscribe
<https://github.com/notifications/unsubscribe-
auth/AACKOPQGRPHWPLMRV3GYDI3XVXFMPANCNFSM5Z6SZ2FQ>.
You are receiving this because you were mentioned.Message ID:
@.***>
--
Sent with HEY https://hey.com/sent

I also see a random focus loss every now and then. 30 seconds send about right.

To be precise: in my case focus is only lost once per each new WT tab/window. In other words, if I start a new tab, focus gets stolen after 30 seconds, but then it does not re-occur until new WT tab/window is started.

I also lose focus in WSL constantlly. I have RSI and depend on using keyboard rather than mouse, and I can't even alt-tab to get the focus back - I have to actually click in the window, otherwise it's completely inaccessible.  This is incredibly annoying. I would be using Linux on bare metal, not Windows at all, but my client thinks it's more secure to require all access to their systems to be via buggy vulnerable crappy software that just gets in the way of productivity. Please fix!

I'm running 1.17.11461.0, and also regularly experiencing a loss of focus in the window. It's quite frustrating. My company also uses Beyond Trust.

I'm also running Windows Terminal 1.17.11461.0, and have Beyond Trust, on Windows 10 Enterprise 22H2 Build 19045.3448. 30 seconds after I open a WSL window, focus is lost. Other application windows are unaffected, I can alt-tab to them and type. But pressing tab or alt-tab does not regain focus in the WSL window, only a mouse click will do. The same thing happens when I open a Powershell or Command Prompt window. It also happens if I close all WSL windows, execute "wsl --shutdown" in a command prompt, then open a Command Prompt or Powershell window - focus lost after 30 seconds, only a mouse click can restore. So problem seems to be with Windows Terminal, not WSL.
It's unclear from above comments whether this is necessarily to do with Beyond Trust. I can say however that I only experience this with Windows Terminal, no other application is similarly affected. In my normal workflow I open and close many WSL windows, and avoid using the mouse due to RSI, so this is both a usability and accessibility issue.

Yeah, I have been having this problem for a while as well. I've just updated to version 1.18.2681.0, but still see this problem. I do have BeyondTrust installed. For people who don't want to use a mouse to regain focus, you can do an ALT+F4 when it loses focus. This way you can close the invisible box and the focus automatically regains on to the most recent terminal you are working on.

Dear Windows Terminal developers, this is really really really annoying bug, and it's actually so surprisingly that MS releases applications with such seriuos and obvious issues (I hope it's not some single person pet project), so please please please fix it 🙏

Thank you, ashpika40, the ALT-F4 trick is brilliant!
My solution now is to open one instance of WT with WSL running in one tab, start tmux and use that for running multiple sessions, splitting windows into panes, etc. For a keyboard-centric user like me this works much better, and you can use the same skills outside of Windows, in pure Linux, ssh sessions, etc etc. I could even do the same thing in cmd.exe, but colors and fonts are nicer in WT.

I would also like to add :  if I open a new Windows Terminal tab or window, and quickly put the focus on a different application like Firefox, after a few seconds the application will lose its focus. The focus is brought to some kind of invisible tab in Windows Terminal
(I also have BeyondTrust, it might be related or a coincidence)
Thanks for looking into this problem, it's very appreciated!

Same problem here, also when commiting with Git.

I commit with Git from the terminal : git commit
It launches Sublim Text (because of some Git config), I type my commit message, save and close the Sublim Text window
Terminal is focused but my tab isn't, I can't type anything until I clicked inside the tab

Any update on this, dear sirs?

@zoulja Yes. Someone should open a bug ticket at BeyondTrust :) They are actually aware that their Privilege Manager does not behave good with some software and constantly fixing it. Unless someone opens a bug ticket, they will not be aware of this misbehavior with WT.

@zoulja Yes. Someone should open a bug ticket at BeyondTrust :)

@ilyaradko I'm facing this bug on my home laptop and I don't have BeyondTrust installed, so actually no need to wait for someone to make it fixed. It's obviously a regression which was introduced a few versions ago

I am facing this since few weeks ago, I am not using BeyondTrust, but I am using other software that perform injection techniques such as StartAllBack and Proxifier. I am on Windows 11.
Is there any low-level "who's asking for focus" tool to run so I can collect useful logs to add here ?

Windows Terminal version
1.14.1451.0
Windows build number
10.0.19042.0
Other Software
No response
Steps to reproduce
Create new pane/new tab
Expected Behavior
It is possible to type in the newly opened terminal
Actual Behavior
Unable to type until I click on the new terminal.
Note that enabling the option "Automatically focus pane on mouse hover" partially prevents the issue from happening.
It seems like focus is removed from all terminal tabs/panes whenever a new one is created.

Still suffering of it in 1.20 Preview

To fix the issue where you can't type in new panes or tabs until manually clicking, check terminal emulator settings, tmux configuration, and shell settings for any conflicts or misconfigurations. Test with default settings, debug, and submit a fix if necessary.

Check Keyboard Focus Settings:
Sometimes, this issue can occur due to keyboard focus settings or accessibility settings. Make sure your keyboard settings are configured correctly.

Restart Windows Terminal:
Close Windows Terminal completely and reopen it. Sometimes, restarting the application can resolve temporary issues like this.

Check for Updates: Ensure that you're using the latest version of Windows Terminal. Older versions may have bugs or issues that have been fixed in newer releases.

Reset Windows Terminal Settings: If the issue persists, you can try resetting Windows Terminal settings to their defaults. This can often resolve configuration-related issues.

Check for Conflicting Software: Sometimes, conflicts with other software can cause issues with keyboard input. Make sure there are no conflicting applications or background processes interfering with Windows Terminal.

If none of these steps resolve the issue, you may need to further investigate or seek assistance from Microsoft support or community forums for Windows Terminal users.

1.19.11213, Windows 11 this issue still exists.

Yeah, Terminal is basically unusable with Visual Studio console programs unless this is fixed. You don't want to need a mouse click when you run your program, before typing things.

I'm not sure why #13640 was closed since it is still an issue that happens on the latest version. This isn't the same issue either, but it was closed as a duplicate anyway by someone who's GH account has been deleted.
TL;DR: can we re-open #13640?

🎂 With a 2nd anniversary of this bug I wish everyone a quick breakthrough! It's been a pain in the neck for all users as well as developers as they are trying to fix something caused by the 3rd party apps in fact.
These words are primarily aimed at you, @zadjii-msft - I hope this will be solved soon and you can forget about that once and for all and focus on some other, most likely much more interesting work!
And thanks for all the efforts to have it sorted out!

Visual studio, start debugging console prog.
Terminal is configured to not use tabbed documents.
If another Terminal window is already open, new window is created unfocused.
If new window is the only Terminal window, it is focused.

Windows Terminal version
1.14.1451.0
Windows build number
10.0.19042.0
Other Software
No response
Steps to reproduce
Create new pane/new tab
Expected Behavior
It is possible to type in the newly opened terminal
Actual Behavior
Unable to type until I click on the new terminal.
Note that enabling the option "Automatically focus pane on mouse hover" partially prevents the issue from happening.
It seems like focus is removed from all terminal tabs/panes whenever a new one is created.

At it appears this is an interaction between Windows Terminal (reproducible with 1.20.11781.0) and BeyondTrust (reproducible with BeyondTrust Client version <IP_ADDRESS>, PMC adapter 23.9.578) on Windows 11 Enterprise (10.0.22621 Build 22621), is it possible that the Terminal team can assemble an equivalent environment to get a repro, and work with BeyondTrust dev team to determine what might be going on here and find a solution?

I don't have BeyondTrust, I don't have any shitty bloatware installed, I even reformatted my computer since I had this issue, and it's still there, on a fresh windows 11 install. The only "exotic" stuff I have installed is WSL 2.0

Still not fixed in the latest Preview build ☹

We merged in a fix that we think is tangential to this problem over in #17828 just today. It should be in this evening's Canary build. Tomorrow, could someone who was seeing the non-WSL focus lost issue test out Canary with a version greater than 1.23.2391.0? That might help us see if this fixed it or not.
You can grab terminal canary from https://aka.ms/terminal-canary-installer
(we'll all be out for the long weekend, so I won't actually know the next canary's build number till like Tuesday)

I'd be happy to. Will do it tomorrow.

I have just tested the Canary version above and it looks very good! 🎉
There STILL IS some focus loss, but it is very short (blink of an eye, literally) and focus immediately returns back to the WT. If that temporary focus loss is long enough to interfere with input - this I cannot tell. But definitely there is a great step forward! 💪
The temporary focus loss is manifested by the mouse cursor re-appearing on the screen (after it has disappeared on keyboard input) and if you use e.g. a red window background for inactive WT window - you can see it blink. This happens ~30 seconds after WT launch/new tab opened too.

I'm super glad to hear it!

There STILL IS some focus loss, but it is very short ...
The temporary focus loss is manifested by the mouse cursor re-appearing on the screen (after it has disappeared on keyboard input) and if you use e.g. a red window background for inactive WT window - you can see it blink. This happens ~30 seconds after WT launch/new tab opened too.

That sounds telltale like some other application is opening for an imperceivable amount of time, then immediately closing. We basically found a slower version of this that involved a git MSAL authentication prompt. That was a clearer example to trace of "another window appears briefly, then closes itself". I doubt whatever is spawning on your machine is an MSAL prompt, but I bet the side effects are similar.
We probably won't be able to do anything about that <1s gap where another window opens into the FG and steals focus, but this at least feels like it'll no longer be blocking for folks.

I will check it again with the script to detect focus-thief used in the
past and let you know.
pt., 30 sie 2024, 13:42 użytkownik Mike Griese @.***>
napisał:

I'm super glad to hear it!
There STILL IS some focus loss, but it is very short ...
The temporary focus loss is manifested by the mouse cursor re-appearing on
the screen (after it has disappeared on keyboard input) and if you use e.g.
a red window background for inactive WT window - you can see it blink. This
happens ~30 seconds after WT launch/new tab opened too.
That sounds telltale like some other application is opening for an
imperceivable amount of time, then immediately closing. We basically found
a slower version of this that involved a git MSAL authentication prompt.
That was a clearer example to trace of "another window appears briefly,
then closes itself". I doubt whatever is spawning on your machine is an
MSAL prompt, but I bet the side effects are similar.
We probably won't be able to do anything about that <1s gap where another
window opens into the FG and steals focus, but this at least feels like
it'll no longer be blocking for folks.
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/terminal/issues/13388#issuecomment-2320961107,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AL5LUZYGNDOZPYH2MHZTI4DZUBLBZAVCNFSM5Z6SZ2F2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMZSGA4TMMJRGA3Q
.
You are receiving this because you were mentioned.Message ID:
@.***>

Tested with script from https://github.com/microsoft/terminal/issues/13388#issuecomment-1357415961
[08/30/2024 13:53:48] Starting WT...
[08/30/2024 13:53:48] ...done
[08/30/2024 13:53:48] Current WT handle: 1118350
[08/30/2024 13:53:48] Current WT process: 8828 / 29892
[08/30/2024 13:53:48] Wating for focus issue to occur.
[08/30/2024 13:53:48] Got new window handle (3409258) after 00:00:00.5859006 - New process: PID: 12252 / TID: 16208 / Name: WindowsTerminal
[08/30/2024 13:54:21] Got new window handle (462284) after 00:00:32.8106372 - New process: PID: 18348 / TID: 13912 / Name: pwsh
[08/30/2024 13:54:21] Got new window handle (3409258) after 00:00:00.0176991 - New process: PID: 12252 / TID: 16208 / Name: WindowsTerminal

It seems it is the same story, where the focus is lost for the shell process that was started in the WT (pwsh in this case), but that happens for much <1s as can be seen above and focus goes immediately back to the WT itself.

That back-and-forth focus tossing is exactly what I was hoping to address with #17829. We'll probably merge that next week and see if that fixes the remaining issues.

I just tested the canary build and it is certainly a large improvement.
Focus does appear to be lost still (the mouse cursor becomes suddenly
visible), but it returns automatically now where before it would not return
without clicking on the terminal.  Ideally focus wouldn't be lost at
all...but this is better -- continuing to type hides the mouse cursor again
and no clicking is needed.
Some noteworthy info:
I am in a corporate environment, running Windows 11 Enterprise 22H2
BeyondTrust Privilege Management is installed
In both Terminal builds (canary and 1.20.11781.0) focus is lost
approximately 35 seconds after opening a new tab
I can type characters one at a time, approximately one second apart and
focus is always lost after 35 seconds or so.
I was not using WSL at the time, just launching a new tab running git bash.
Thank you for working on this issue, it is maddening!
On Fri, Aug 30, 2024 at 8:01 AM Adam Purcell @.***>
wrote:

In my case, Terminal works just fine until I open the Outlook Office 365
Client. I can navigate panes using keyboard shortcuts like Alt + Up / Down
but can't select with mouse. Toolbar buttons are also disabled. When I
close Outlook, it works just fine again. I also tried the Canary release
mentioned above with the same results. I'm using the Outlook web client as
a workaround.
OS Name:                   Microsoft Windows 11 Enterprise
OS Version:                10.0.22631 N/A Build 22631
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/terminal/issues/13388#issuecomment-2321179155,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEVIQPEHMTTUT6VW77N2GDZUBUKRAVCNFSM5Z6SZ2F2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMZSGEYTOOJRGU2Q
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

It works. It still loses focus for a split second and comes back. If you keep typing when this happens you might loose a character, Other than that, excellent job. Finally, I will shift to Terminal completely . Tested on win 10 enterprise 22H2 with beyondTrust and using gitbash for testing

We were happy a bit too soon - there's another scenario we did not test: start Windows Terminal (or a new tab), switch to some other application and wait. This time WT steals focus and all the input goes to the WT console. Which is dangerous (e.g. when typing password, or the "rm -rf /foo/bar" command in the other window or app).
See the output from the PowerShell script (already used in the previous comments) below. Test steps taken - with the script started in the stand-alone Windows PowerShell window, i.e.: not in WT:

Launched script which spawns new WT tab/windows/process.
At 09:34:01 I have manually switched the application focus to Firefox (with a mouse-click directly on the Firefox window)
At 09:34:29 WindowsTerminal steals the focus completely.
At 09:34:34 I have manually switched the application focus back to Firefox.

[10/01/2024 09:33:55] Starting WT...
[10/01/2024 09:33:55] ...done
[10/01/2024 09:33:55] Current WT handle: 528338
[10/01/2024 09:33:55] Current WT process: 6616 / 6220
[10/01/2024 09:33:55] Wating for focus issue to occur.
[10/01/2024 09:34:01] Got new window handle (0) after 00:00:05.7594232 - New process: PID: 0 / TID: 0 / Name: Idle
[10/01/2024 09:34:01] Got new window handle (396212) after 00:00:00.0368753 - New process: PID: 13056 / TID: 22520 / Name: firefox
[10/01/2024 09:34:29] Got new window handle (593880) after 00:00:28.3067264 - New process: PID: 25360 / TID: 26136 / Name: WindowsTerminal
[10/01/2024 09:34:34] Got new window handle (0) after 00:00:05.2914857 - New process: PID: 0 / TID: 0 / Name: Idle
[10/01/2024 09:34:34] Got new window handle (396212) after 00:00:00.0331324 - New process: PID: 13056 / TID: 22520 / Name: firefox

Unfortunately this new behaviour is even more annoying (and dangerous) than the old one...

On Windows 11 I can still observe the focus theft with the latest WT (1.21.2911.0)


[JENKINS-55787] Switch labels from entry to checkbox

https://issues.jenkins-ci.org/browse/JENKINS-55787
Basically checkboxes should have labels, splitting the labels away from their checkboxes is poor UX, poor accessibility. This change brings the layout more inline with how normal settings UIs lay out checkboxes.
This supersedes #117

Could you please attach a screen capture of how to it is showing it before and after in relation with the rest of fields?  I think it breaks the form view.

Today:

With this patch:

Going forward as part of jenkinsci/jenkins#3895:

it without https://github.com/jenkinsci/jenkins/pull/3895 it looks weird, but I like it too much with the whole solution. The only NIT is the help button. So I will monitor the 3895 and as soon it was merged this will be merged

@kuisathaverat : btw, do you have any particular input on the help button? -- See https://github.com/jenkinsci/jenkins/pull/3895#issuecomment-464588474

I saw that https://github.com/jenkinsci/jenkins/pull/3895 is closed so I guess this one has to be closed too, isn't it?

I still intend to get it done eventually. I might even try to poke the UX SIG this week.

cool, I'll keep it open

Without the change

With the change

@jsoref
The changes you made on the core are so good that the PR is not needed anymore, thank you, if you are OK we can close the PR.


Effects

Add effects and their routing. Work in progress

Effect factory

Designed such that it can receive user-defined effects.
An effect is designated by its "type" opcode.

Routing with main bus and up to 256 effect buses
Mixing per-region
Basic "lofi" effect to start which is relatively CW-compliant

TODO

review the mixing behavior in case of use of main/fx buses together, or one of these only

There are still some things and dirty and it's not tried.
Regardless, I submit the code for review if you would like to have a peek.
Remark: I would like if we can introduce HIIR downsampler separately of this PR

Below some sfz for testing
Bitcrusher on main bus
<region>
lokey=0
hikey=127
sample=*sine

<effect>
type=lofi
bitred=90
decim=10

Bitcrusher on bus 1, main bus turned off
<region>
lokey=0
hikey=127
sample=*sine
effect1=100

<effect>
directtomain=0
fx1tomain=100
type=lofi
bus=fx1
bitred=90
decim=10

Bitcrusher on bus 1, main and fx1 mixed 50/50
<region>
lokey=0
hikey=127
sample=*sine
effect1=100

<effect>
directtomain=50
fx1tomain=50
type=lofi
bus=fx1
bitred=90
decim=10

All good for me, can merge :) Thanks alot!

On blockSize and sampleRate : I don't really agree with the renaming setSampleRate
The entry point init is really intended for an initialization role.

It should setup anything which is rate dependent, and clear the state.
It should not modify the values of parameters

I would suggest to pass both of sample rate and buffer size to this init method.
For information, I wish this process to be equivalent with a design of future C API which can be used for registering external effects into sfizz.
(in such a way, we can register MDA's effect package externally like Sforzando, or do anything custom)

OK, I'm good with this, I'll update.


[Coverity CID :143683]Error handling issues in /subsys/fs/fcb/fcb.c

Static code scan issues seen in File: /subsys/fs/fcb/fcb.c
Category: Error handling issues
Function: fcb_offset_last_n
Component: Other
CID: 143683
Please fix or provide comments to square it off in coverity in the link: https://scan9.coverity.com/reports.htm#v32951/p12996

 	A1. example_checked: Example 1: fcb_getnext(fcb, &loc) has its value checked in fcb_getnext(fcb, &loc).
301        while (!fcb_getnext(fcb, &loc)) {
   	3. Condition i == 0, taking true branch.
   	7. Condition i == 0, taking false branch.
302                if (i == 0) {
303                        /* Start from the beginning of fcb entries */
304                        *last_n_entry = loc;
   	4. Falling through to end of if statement.
305                }
306                /* Update last_n_entry after n entries and keep updating */
   	8. Condition i > entries - 1, taking true branch.
307                else if (i > (entries - 1)) {

CID 143683 (#1 of 1): Unchecked return value (CHECKED_RETURN)
9. check_return: Calling fcb_getnext without checking return value (as is done elsewhere 5 out of 6 times).
308                        fcb_getnext(fcb, last_n_entry);
309                }
310                i++;
   	5. Jumping back to the beginning of the loop.
311        }

The while loop uses the return value of fcb_getnext() to continue looping but we also have a call to fcb_getnext() without a check of the return value? This seems potentially suspect but if okay than you will need to prepend the call with (void) to get around the coverity issue.


ffpyplayer crashes on Linux after a number of files played

Software Versions

Python: 3.8 and 3.10
OS: Ubuntu 18.04 and Ubuntu 22.04
Kivy: 2.1.0, 2.2.0, 2.2.1
Kivy installation method: pip and compiled from source on the platforms

Describe the bug
When playing a ogg sound file while using ffpyplayer as the audio provider after 15 times playing the ffpyplayer will crash:
[WARNING] [ffpyplayer  ] [ffpyplayer_abuffersink @ 0x7f99b0006a80] Removing channel layout 0x4, redundant with 1 channels
[WARNING] [ffpyplayer  ] [ffpyplayer_abuffersink @ 0x7f99b001fac0] Removing channel layout 0x4, redundant with 1 channels
[WARNING] [ffpyplayer  ] SDL_OpenAudio (1 channels, 48000 Hz): Too many open audio devices
[WARNING] [ffpyplayer  ] SDL_OpenAudio (1 channels, 44100 Hz): Too many open audio devices
[ERROR  ] [ffpyplayer  ] No more channel combinations to try, audio open failed
[CRITICAL] [ffpyplayer  ] Failed to open file '/mnt/nvme0n1p1/Github/btp-kivy/test_opus.ogg' or configure filtergraph
A way to prevent the crash is to unload the file after it played. See also the test code below.
It doesn't matter if we install kivy with pip on python 3.8 or 3.10 or compile kivy for those platforms. Ffpyplayer will always crash after a few times playing if you don't unload the file.
We also tried using different versions of ffmpeg but it makes no difference.
This problem occurs on all kind of hardware, we have thousands of systems in use in about 10 different hardware configurations and all experiences this problem if we don't unload the sound after playing. This was also the reason we compiled our own kivy with gstreamer support the last few years but unfortunately newer python/kivy versions don't compile anymore with gtreamer support on Ubuntu 22.04 so we needed a hack to prevent the ffpyplayer from crashing.
Expected behavior
Don't crash ;-)
To Reproduce
Use the provided code example but just playing a file more then 15 times will also crash ffpyplayer.
I couldn't attached the code and the test ogg file. The ogg file is a opus ogg produced by google TTS.
But the crash will also happen with any other ogg/mp3 file.
Run the code as is, with 'do_unload' set to False.
Setting the 'do_unload' to True will prevent the crash.
Code and Logs and screenshots
The test code starts with playing without unloading and when you set the global var 'do_unload' to True it will start and unload each file after it plays.
soundfile = 'test_opus.ogg'
do_unload = True

import os
os.environ['KIVY_NO_FILELOG'] = "1"
os.environ['KIVY_GL_BACKEND'] = 'sdl2'
os.environ['KIVY_VIDEO'] = 'ffpyplayer'   #'gstplayer'
os.environ['KIVY_AUDIO'] = 'ffpyplayer' #gstplayer'

from kivy.lang import Builder
from kivy.uix.boxlayout import BoxLayout
from kivy.app import App
from kivy.core.audio import SoundLoader

Builder.load_string("""
<Content>:
    Button:
        text: "Press me to start playing sound"
        size_hint: (0.5, 0.5)
        on_press: root.start_play()
""")

class Content(BoxLayout):

    def __init__(self, **kwargs):
        super().__init__(**kwargs)
        self.current_sound = None

    def start_play(self, *args):
        if self.current_sound and do_unload:
            print("Unloading previous sound")
            self.current_sound.unload()
        self.play()

    def play(self, *args):
        sound = SoundLoader.load(soundfile)
        self.current_sound = sound
        sound.bind(on_stop=self.start_play)
        sound.play()

class TestApp(App):

    def build(self):
        fl = Content()
        return fl

TestApp().run()

Additional context
This is an issue we have a couple of years now and we compiled kivy our self with gstreamer support. But as our older OS versions aren't compiling anymore with newer kivy versions we must use ffpyplayer now with the unload "fix".
This way we use ffpyplayer and kivy on our thousands Ubuntu 18.04 and 22.04 systems without any issues.
This problem was also discussed on the group ML: https://groups.google.com/g/kivy-users/c/m28VkNVfwpo

Is the same issue happening if you use ffpyplayer directly, without Kivy (e.g. in a cli demo script)?
That would help redirecting the issue to the proper channel (kivy or ffpyplayer)

Not sure how to use ffpyplayer directly as the docs only talk about transcoding etc and this will produce  a core dump:
from ffpyplayer.player import MediaPlayer
player = MediaPlayer('test_opus.ogg')
Ps, the solution isn't difficult. We use a patched version of the kivy/core/audio/ffpyplayer by adding self.unload() to the 'stop' method of the SoundFFPy class. (By using the environ['KIVY_DATA_DIR'] env var, we patch more stuff like opencv)
I can make a one line PR if you want but it's pretty trivial to fix this.

It seems the issue is more troublesome then I suspected.
The unloading seems to prevent the issue but after a longer time the "Too many open devices" returned :-(

And this is on a kivy 2.2.1 compiled with gstreamer support but using ffpyplayer by setting
os.environ['KIVY_AUDIO'] = 'ffpyplayer'
[WARNING] [ffpyplayer  ] SDL_OpenAudio (2 channels, 44100 Hz): Too many open audio devices
[WARNING] [ffpyplayer  ] SDL_OpenAudio (1 channels, 44100 Hz): Too many open audio devices
[ERROR  ] [ffpyplayer  ] No more channel combinations to try, audio open failed
[CRITICAL] [ffpyplayer  ] Failed to open file '/opt/App/BtpKivy_Xf_19.2/lib/SPData/sounds/silence_1000.ogg' or configure filtergraph

We never had this issue prior to kivy 2.2.1 :-(

Looks like a (old?) ffpyplayer/sdl issue: https://github.com/matham/ffpyplayer/issues/71
It has the exact same errors


Feature request: More style config

Just a small addition to config to set minimum box size in symbols/lines, so instead of:
###########
# COMMENT #
###########

It will do:
###################################
#             COMMENT             #
###################################

Or:
###################################
#                                 #
#             COMMENT             #
#                                 #
###################################

Also maybe some symbol configs for empty lines?
Like so:
/*┌────────────────────────────┐
  │ Lorem ipsum dolor sit amet │
  │        comments here       │
  ├────────────────────────────┤
  │      after empty line      │
  └────────────────────────────┘*/

Hello! I noticed you've closed this issue, but still I would like to add a little context about what I did / didn't do.
I've added 2 settings that allow what your first comment suggests. boxWidth for
###################################
#             COMMENT             #
###################################

and removeEmptyLines for
###########
#         #
# COMMENT #
#         #
###########

As for the last suggestion, I considered them but there are a few problems:

it makes the configuration more complicated, I'd prefer less options if possible
I don't think people need this a lot (I could be wrong)
most importantly, it takes a while to implement because it interacts badly with the need to detect comment boxes, and I don't have much time to spend on this

Thanks for the suggestions, and if you really need that last one please let me know : )


new logo overhaul

New logo & favicons
also added a logo.svg in static folder
https://github.com/khusika/FeelIt/issues/36

thanks for this, but I have my own design view for the logo.


The latest version 2.0.4 contains the fix for this issue.


upsun: init at 5.0.12

Description of changes

New package for upsun product https://github.com/platformsh/cli/releases/tag/5.0.12 using pre-build binary
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 299451 run on x86_64-linux 1

1 package built:

upsun

reason for not building from source?
also, if you are going to include a prebuilt binary, please set meta.sourceProvenance appropriately.

reason for not building from source?

The build is currently complicated using docker and other static binaries but it could change in the future

also, if you are going to include a prebuilt binary, please set meta.sourceProvenance appropriately.

Thanks I've applied the option

This package is still possible to build from source. Also, https://github.com/platformsh/cli/blob/main/scripts/generate_completions.sh can generate shell completion for you.

This package is still possible to build from source. Also, https://github.com/platformsh/cli/blob/main/scripts/generate_completions.sh can generate shell completion for you.

Thanks for the review. I will try to work on the shell completion next.


Adding Regular pentagon in Calculator for Shapes

I Want to add Regular pentagon in calculator for shapes.
Please assign this to me under GSSoC.

You can go ahead with this one :)
Deadline 20 April 11:59 PM IST


[ENHANCEMENT] Add integration test to Harvester dependency repos

Is your enhancement related to a problem? Please describe.
We need to add integration tests to Harvester dependency repos.
Describe the solution you'd like

leverage the GH self-hosted runners to set up the CI, and we can benefit from the bare-metal customization and VM-level simulations.
add Github Action CI hook for each pull-request change.
add proper integration test cases.

Related Repos:

[ ] harvester/network-controller-harvester
[x] harvester/node-disk-manager
[ ] harvester/node-manager
[ ] harvester/load-balancer-harvester
[ ] harvester/cloud-provider-harvester
[ ] harvester/harvester-csi-driver
[ ] harvester/pcidevices
[ ] harvester/vm-import-controller

Additional context
e.g., https://github.com/harvester/node-disk-manager/blob/master/.github/workflows/basic-ci.yaml

To assign component owners.


fuel.ignition.org to fuel.gazebosim.org

As Ignition is now Gazebo (the name we all love). The models loading from Fuel Ignition (still old name) url is changed.
The models with loading from the Fuel Ignition, the cloud model library, need url changed.
This should fix https://github.com/Field-Robotics-Lab/dave/issues/27
I will add some text in dave.doc for loading time (in my system, it took almost 5 minutes to download all models)

Added to WG kanban https://github.com/orgs/ros-maritime/projects/1

Hmm, I see that these are the new models we added in 2021. We have a copy of these on Fuel, those might need to be re-uploaded as well...
 We just had the same kind of error cropped up in the splash screen worlds in Harmonic today.

Oh wow.. I haven't tested everything but the ones I've tested worked. This changes were first brought up after issues that the world was not launching. Modifying the URL as in this PR fixed it.

Oh I meant in the diff for examples/dave_demo_launch/launch/dave_integrated_demo.launch, there's still a lot of other commented tags. Do they all need to be commented? The joystick was just one of many.


Add a blade component for the front page blocks.

A blade component for the front page blocks minimizes the boilerplate
for adding new blocks. It also makes it easier for a service
to override the front view and add their own blocks.

Question: Do we need to support php 7.4?
The tests are failing because I was using php 8 constructor property promotion.
I could easily change it...unless we want to support only php 8+. :)

Question: Do we need to support php 7.4?
The tests are failing because I was using php 8 constructor property promotion.
I could easily change it...unless we want to support only php 8+. :)

Done, https://github.com/glesys/butler-service/pull/64 :tada:


Tag a new release

Is it possible to tag a new release for Github and Forge?
Thanks! 👍

Yup! 0.4.0 has hit the forge.