WIN prevent deadlock in SetForegroundWindow

As mentioned in various blogs, like Raymon Chens "The old new
thing", 2008-08-01, "I warned you: The dangers of attaching input
queues", using AttachThreadInput to steal the input from an other
thread, so SetForegroundWindow becomes more reliable, can
deadlock in that call in win32u.dll!NtUserCallHwndLock.

Stackoverflow also has a multitude of suggestions and links in
"Win32 SetForegroundWindow unreliable", to circumvent Windows
focus-stealing prevention mechanisms.

A customer is experiencing these hangs reliably and often when
opening LO windows via Java UNO, because the Window and the UNO
thread are different and trigger this code path. Removing the
calls to AttachThreadInput fixes the problem for them. This has
started lately and nobody really knows why.
I also know other customers with a similar Java UNO setup, which
don't experience them.

For better foreground handling, the calling app eventually should
either use AllowSetForegroundWindow or CoAllowSetForegroundWindow
(for COM servers), to give up the foreground / input handling.

So this just drops the AttachThreadInput calls.

Change-Id: I8de0a17aaaa44c24b1ee728b2ef6ec3aea951c54
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89527
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

0 files changed, 0 insertions, 0 deletions