Keyboard focus does not pass on Windows 11.

[apodtele]

Launching ftgamma from mintty opens its window in the background without passing the keyboard focus. Cmd, on the contrary, does it properly and passes the focus. This is observed with Git-for-Windows 2.40.0 based on MSYS2. Ftgamma is a simple Windows program with nothing beyond basic CreateWindow and GDI.

[apodtele]

Windows 11 behaves just weirdly when I start standard pbrush.exe from mintty: pbrush.exe starts in the background but mintty also loses focus. Wow.

[mintty]

Where is the source of this ftgamma and can it be compiled with cygwin tools?
Does it happen on Windows 10 with this demo tool?

[mintty]

Launching ftgamma from mintty ...

I suppose you mean running the program from a command line.
This is not really launching from mintty. It is the shell that launches the programm, mintty isn't involved.
I am therefore inclined to close the issue as invalid. It must be some weird interworking triggered by the launched program in Windows 11. Leaving open yet for a while as someone may come up with an analysis.

[apodtele]

Paint Brush (pbrush.exe) comes standard with any Windows version since Windows 95. If you can start that from a mintty command line without any focus surprises on Windows 11 then so be it. Close this as "invalid" or "works for me", or help me find where to file this bug report..

[mintty]

There is no pbrush.exe in my Windows 10 installation.
What about mspaint?
For clarity please answer my question: how exactly do you "launch" the program?

[apodtele]

I start the programs by typing "pbrush.exe" from the command line. I use Git for Windows which is rather minimalist installation of MSYS2 with mintty, bash, vim, and git. I compile FreeType (hence, ftgamma too) using an msbuild alias (without MSVC IDE, mind you). This works perfectly for me and as a rather light weight development environment.

Recently, I switched to Windows 11 and my shenanigans with freetype-demos for testing freetype began. Those tools are meant to be used from command line but show windows.

[apodtele]

Yes pbrush and mspaint are probably the same. I guess Windows 11 resurrected the old name.

[mintty]

It seems to be a problem only on Windows 11 which I don't have so I cannot analyse it.

[apodtele]

Perhaps this: https://betanews.com/2023/01/05/windows-11-22h2-has-introduced-an-irritating-focus-bug-in-file-explorer/

[mintty]

Are you on Windows "fast release track"? Can you downgrade and retest? Or just wait until the fix...
To check whether a workaround is possible, you could use cygwin or MSYS2 (with packages gcc and make), recompile mintty with make CCOPT=-Ddebug_messages, cut or mark the trace where the launch command is entered, and upload it here.

[apodtele]

This is regular Windows 11 22H2 on the brand new Dell. The diagnostic shows that explorer.exe interjects twice and steals the focus. Besides mspaint.exe/pbrush.exe, calc.exe reliably starts out of focus for me. The calculator taskbar icon blinks too to indicate that it could not get focus.. Weird... I uninstalled McAfee, which did not help, but left a bunch of Dell software on for now.

[BrianInglis]

Under mintty should use cygstart to launch Windows GUIs e.g.
$ cygstart pbrush

[apodtele]

Under mintty should use cygstart to launch Windows GUIs e.g. $ cygstart pbrush

Please educate me why this is necessary. Or, why cannot bash do it?

Also, cygstart does not come with git-for-windows. Which package is it a part of?

[mintty]

The diagnostic shows that explorer.exe interjects twice and steals the focus.

Which diagnostic actually? Is there any unusual message sending towards mintty that could be handled as a workaround?
Mintty message diagnostic can be enabled with compiling make CCOPT=-Ddebug_messages. If someone can demonstrate a difference between flawed behaviour (Windows 11?) and normal behaviour (Windows 10?) maybe we can get further.

[apodtele]

Video posted.

[thedmd]

I have this issue on Windows 11 22H2 (OS Build 22621.1992), on Windows 10 it is working fine.
Windows 11 was installed from ISO, it was not an upgrade from 10.

[apodtele]

Thanks, I am glad that I am not alone.

I don't know how calc or mspaint designed. My programs CreateWindow and ShowWindow from a child thread expecting the active keyboard focus there. This may or may not be an important reason why the main thread started by mintty mistakenly keeps the focus.

[mintty]

I have now tested this with Windows 11 and I do not reproduce the issue.
Running calc from a shell in mintty transfers focus to calc for me.

[apodtele]

I am not sure if it matters, but I guess that you tested a current msys2 installation with bash. I would like to try your setup before squarely blaming Git-for-Windows.

[mintty]

I run cygwin. I can hardly imagine this should make a difference but who knows.
Please also check your $PS1 prompt, or clear it (PS1=.) for a cross-test.

[thedmd]

Issue still persist with:

I would put my money on bug in Explorer, on Windows 10 focus still behave ok.

[mintty]

Current version is actually 3.4.8.

Please also check your $PS1 prompt, or clear it (PS1=.) for a cross-test.

Just to make sure there is no escape sequence that would explicitly trigger this behaviour.

[thedmd]

By $PS1 do you mean to use Windows PowerShell or PowerShell passed through mintty? Sorry, I'm not well versed in terminals.

So far I'm testing using git from Windows PowerShell and here focus behave correctly.

[mintty]

No, PS1 is a Unix/Linux/Cygwin shell variable to configure the prompt string. No PowerShell involved.
Please set PS1=. then run calc again.

[thedmd]

I did set PS1=. and typed calc. Calculator showed up under terminal window.

This is still one from latest Git for Windows. I need to look into installing latest version independently.

[thedmd]

I installed latest nightly of msys2. Same result.

pacman report mintty 1~3.6.5-1 after an update mintty 3.6.5 (x86_64-pc-msys). Same result.

I tried Windows Terminal with Git Bash and focus does work ok.

[apodtele]

I filed with msys2-runtime as a point of departure from cygwin.

[mintty]

Did you cross-check on Windows 11/cygwin?
I plan to cross-check with Msys but my Windows 11 machine is currently packed away...

[apodtele]

Yes, I can confirm that cygwin passes focus. msys2 does not.

[mintty]

I do not reproduce that. Just installed MSYS2 and Git for Windows on Windows 11 and it works for me.

[thedmd]

Version of windows I have:

Edition		Windows 11 Pro
Version		22H2
Installed on	‎11.‎04.‎2023
OS build	22621.2283
Experience	Windows Feature Experience Pack 1000.22662.1000.0

[apodtele]

Edition		Windows 11 Home
Version		22H2
Installed on	‎3/‎19/‎2023
OS build	22621.2283
Experience	Windows Feature Experience Pack 1000.22662.1000.0

[ElvenSpellmaker]

I just updated my Git for Windows (2.39.2 - mintty 3.6.3) and I can reproduce this too, never on Cygwin. So it seems to be a bug with msys2.

$ cmd /c ver

Microsoft Windows [Version 10.0.22621.2861]

(I'm actually on 22H3 despite that the output above might hint at me being 22H2. I downloaded the package and installed manually).

[apodtele]

Other issues related to focus get some attention lately #1207, #1242, #1249. Perhaps it will all resolve one day.

[mintty]

Those other issues are all related to multiple tabs, so I guess it's something different.
Can someone test whether it happens on plain MSYS2 (not Git for W)?

[apodtele]

Confirmed on vanilla msys2/msys2-runtime/issues/173.

This bug was introduced then the tab focus work begun. It may be a coincidence.