[Libreoffice-commits] core.git: vcl/win

Jan-Marek Glogowski (via logerrit) logerrit at kemper.freedesktop.org
Wed Feb 26 16:03:07 UTC 2020


 vcl/win/window/salframe.cxx |    9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

New commits:
commit 518c0265efebf39ab6d1e90c4ec4e7cf52b701c6
Author:     Jan-Marek Glogowski <jan-marek.glogowski at extern.cib.de>
AuthorDate: Tue Feb 25 10:02:25 2020 +0100
Commit:     Jan-Marek Glogowski <glogow at fbihome.de>
CommitDate: Wed Feb 26 17:02:32 2020 +0100

    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 at fbihome.de>

diff --git a/vcl/win/window/salframe.cxx b/vcl/win/window/salframe.cxx
index 0321dd731a35..2a125deeddab 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 )


More information about the Libreoffice-commits mailing list