summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJan-Marek Glogowski <jan-marek.glogowski@extern.cib.de>2020-02-25 10:02:25 +0100
committerNoel Grandin <noel.grandin@collabora.co.uk>2020-02-27 07:28:21 +0100
commitaf3033e5546648bacdac3187caf2be6d5ea34f77 (patch)
tree0f850958e61160773b330de75e1a5715abdebb07
parent98ce08d22f39558955d5c3320a25583380d47146 (diff)
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> (cherry picked from commit 518c0265efebf39ab6d1e90c4ec4e7cf52b701c6) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89572 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
-rw-r--r--vcl/win/window/salframe.cxx9
1 files changed, 1 insertions, 8 deletions
diff --git a/vcl/win/window/salframe.cxx b/vcl/win/window/salframe.cxx
index a57e67ce8896..aedba78e3fca 100644
--- a/vcl/win/window/salframe.cxx
+++ b/vcl/win/window/salframe.cxx
@@ -1934,15 +1934,8 @@ static void ImplSalToTop( HWND hWnd, SalFrameToTop nFlags )
if ( nFlags & SalFrameToTop::ForegroundTask )
{
- // This magic code is necessary to connect the input focus of the
- // current window thread and the thread which owns the window that
- // should be the new foreground window.
- HWND hCurrWnd = GetForegroundWindow();
- DWORD myThreadID = GetCurrentThreadId();
- DWORD currThreadID = GetWindowThreadProcessId(hCurrWnd,nullptr);
- AttachThreadInput(myThreadID, currThreadID,TRUE);
+ // LO used to call AttachThreadInput here, which resulted in deadlocks!
SetForegroundWindow_Impl(hWnd);
- AttachThreadInput(myThreadID,currThreadID,FALSE);
}
if ( nFlags & SalFrameToTop::RestoreWhenMin )