We got a really weird bug report in issue 6324 where multiple Word windows kept restacking when the user moved the mouse over certain areas. I was able to reproduce it here on our version of office (XP) using the following method: 1. Start Word 2. Type something in the document, then press "New" to get a second window 3. Make sure the second window is on top of the window stack 4. Move the mouse pointer over one of the toolbar buttons so that a tooltip pops up 5. Move the mouse pointer away so that the tooltip disappears At this point it restacks the windows so that the first window is on top. You can see the problem appearing already when the tooltip is created. I suspect some improper parenting.
(In reply to comment #0) > At this point it restacks the windows so that the first window is on top. You > can see the problem appearing already when the tooltip is created. Tried to reproduce on eudemo. When the tooltip appears, the first window is indeed raise. You can see it in the task bar; it's highlighted. However, when the mouse is moved away from the tooltip, the second window is again activated. So slightly different result but probably the same underlying bug.
Created attachment 588 [details] seamless_tooltip_issue.log Enabled seamless debug and reproduced the issue. Cleaned the log file so it contains relevant information and added some comments. One potential source to the problem was identified, a FOCUS is performed on the window for the first empty document.
(In reply to comment #5) > One potential source to the problem was identified, a FOCUS is performed on the > window for the first empty document. Looking at the code path for the DESTROY message of the tooltip I could not find any obvious reasons for the send of FOCUS message. However, FOCUS is only sent in one place in rdesktop and that is when XEvent FocusIn is raised for a window.
The attached logfile shows that When the tooltip window is created the parent window is 0x0003002a which actually should be the second document window 0x00020076.
(In reply to comment #7) > The attached logfile shows that When the tooltip window is created the parent > window is 0x0003002a which actually should be the second document window > 0x00020076. Looking at the code for SeamlessRDP (hookdll.c) the parent window is fetched using getWindow(this, GW_OWNER); which obviously is wrong. This might be a bug in winword, need to find a testcase without winword to prove the case.
(In reply to comment #8) > (In reply to comment #7) > > The attached logfile shows that When the tooltip window is created the parent > > window is 0x0003002a which actually should be the second document window > > 0x00020076. > > Looking at the code for SeamlessRDP (hookdll.c) the parent window is fetched > using getWindow(this, GW_OWNER); which obviously is wrong. This might be a bug > in winword, need to find a testcase without winword to prove the case. > Information about owned windows: http://msdn.microsoft.com/en-us/library/windows/desktop/ms632599(v=vs.85).aspx#owned_windows
(In reply to comment #8) > (In reply to comment #7) > > The attached logfile shows that When the tooltip window is created the parent > > window is 0x0003002a which actually should be the second document window > > 0x00020076. > > Looking at the code for SeamlessRDP (hookdll.c) the parent window is fetched > using getWindow(this, GW_OWNER); which obviously is wrong. This might be a bug > in winword, need to find a testcase without winword to prove the case. Another variable to this play; The problem is only reproducible once, sub-sequential tooltips does not provoke the issue following the protocol: 1. Start word 2. Open a new word instance from toolbarbutton 3. Hoover over a toolbutton for a tooltip 4. Leave tooltip and the first instance of word will be focused 5. Bring focus back to second window by clicking titlebar 6. All sub-sequential tooltips works as expected.
(In reply to comment #10) > > 1. Start word > 2. Open a new word instance from toolbarbutton > 3. Hoover over a toolbutton for a tooltip > 4. Leave tooltip and the first instance of word will be focused > > 5. Bring focus back to second window by clicking titlebar > 6. All sub-sequential tooltips works as expected. The reason seems to be that there are broken logic in rdesktop to track focused window, g_seamless_focused. At point 4, the logic will send a FOCUS message to wrong window (OWNER). At point 6, there there will be 2 FocusIn XEvents from the window manager one for the owner and one for the correct window. This case will be handled ok with the focus logic. We need to iron out why there are two FocusIn XEvent for both windows when tooltip window is destroyed.
(In reply to comment #9) > Information about owned windows: > > http://msdn.microsoft.com/en-us/library/windows/desktop/ms632599(v=vs.85).aspx#owned_windows http://blogs.msdn.com/b/oldnewthing/archive/2010/03/15/9978691.aspx
After further testing the conclusions are that there are bad behaviors in the winword regarding how windows are handled. Winword tries to handle all its own windows overriding the window manager and that's probably why we see that the OWNER window is another than expected using SeamlessRDP. To show the bad behavior following these steps on a desktop with winword: 1. Start instance A of winword 2. From toolbar start instance B 3. From instance B toolbar choose open for open dialog 4. Any try to put instance A on top either by titlebar or from taskbar will fail. One will see that winword tries to handle which window has focus and prevent to change the order. Testing the above with OpenOffice shows the correct behavior.
(In reply to comment #13) > > Testing the above with OpenOffice shows the correct behavior. Also verified that using OpenOffice there is not problem with tooltips when trying reproduce the origin issue with SeamlessRDP.
(In reply to comment #8) > (In reply to comment #7) > > The attached logfile shows that When the tooltip window is created the parent > > window is 0x0003002a which actually should be the second document window > > 0x00020076. > > Looking at the code for SeamlessRDP (hookdll.c) the parent window is fetched > using getWindow(this, GW_OWNER); which obviously is wrong. This might be a bug > in winword, need to find a testcase without winword to prove the case. winword sets the owner for the the tooltip to the wrong window, probably because it tries to be a window manager for windows spawned from same winword.exe process. A workaround has been added to SeamlessRDP in upstream commit r1841, which ignores the OWNER window if window is of class "OfficeTooltip"
(In reply to comment #15) > (In reply to comment #8) > > (In reply to comment #7) > > > The attached logfile shows that When the tooltip window is created the parent > > > window is 0x0003002a which actually should be the second document window > > > 0x00020076. > > > > Looking at the code for SeamlessRDP (hookdll.c) the parent window is fetched > > using getWindow(this, GW_OWNER); which obviously is wrong. This might be a bug > > in winword, need to find a testcase without winword to prove the case. > > winword sets the owner for the the tooltip to the wrong window, probably > because it tries to be a window manager for windows spawned from same > winword.exe process. > > A workaround has been added to SeamlessRDP in upstream commit r1841, which > ignores the OWNER window if window is of class "OfficeTooltip" Brought to ctc with vendor drop commit 29580.
There is no workaround for the issue described in comment #13. Closing this bug.
Tested this with Office 2013 on Windows 2008R2, which is unfortunately not the sambe combination used whilst fixing this bug. Most of the tooltips in the new Office behave just fine in 4.3.0. However those on the status bar entries still exhibit problems. With the new version in place even those tooltips work just fine though. So I consider this bug properly implemented and tested.
