Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 509947

Summary: [win32] Rollover tooltip on TreeItem of non-focused shell drawn at wrong place
Product: [Eclipse Project] Platform Reporter: Markus Keller <markus.kell.r>
Component: SWTAssignee: Markus Keller <markus.kell.r>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: arunkumar.thondapu, daniel_megert, markus.kell.r, niraj.modi, straitg
Version: 4.7   
Target Milestone: 4.7 M6   
Hardware: PC   
OS: Windows 7   
Whiteboard:
Bug Depends on:    
Bug Blocks: 491627    
Attachments:
Description Flags
Screenshot none

Description Markus Keller CLA 2017-01-04 13:33:21 EST 
Created attachment 266125 [details]
Screenshot

I20170102-2000

Bug 491627 was too nice to be true.

I have not debugged it yet, but I'm pretty sure that change is the reason for misplaced rollover tooltips on TreeItem of non-focused shells, see screenshot.

I initially saw this in EGit's "Pull Result" dialog. For custom-draw trees like that one, the tooltip only shows the image, but not the text. The same happens when I detach the Package Explorer and then activate the workbench window again.

For plain trees, the full label gets rendered, but at a wrong place.

Options:

A) Try to completely suppress tooltips for inactive shells

B) Try to detect whether the application is active and keep the old code in that case. Bug 491627 was only a problem when the application has no active shell.

C) Try to properly support tooltips in this scenario.
Comment 1 Markus Keller CLA 2017-02-01 14:28:21 EST 
The problem is that the current fix for bug 491627 also blocks some TTN_SHOW requests from an inactive shell of the active application.

I've tried setting breakpoints and tracepoints in may places, but I couldn't find anything in SWT that would still make the shell with the tree in bug 491627 comment 7 raise to the top. I assume it's a bug in Windows. I also tried to detect the condition when the WM_WINDOWPOSCHANGING message is sent, but I didn't find a way to distinguish the bad messages from the ones that are fine.


The original scenario from bug 491627 and bug 497929 is quite bad. Those cases are still fixed when we change the condition to:

	if (display.getActiveShell () == null) return LRESULT.ONE;

This fix leaves scenarios in the active application untouched. In the active application, the tradeoff is between:

a) accept cases where a rollover tooltip raises a shell to top in the active app
   => condition with " == null"

b) accept misplaced and wrongly sized rollover tooltips (screenshot; even worse in EGit's "Pull Result" dialog)
   => condition with " != getShell ()" (original fix)

Since (b) is quite annoying and we didn't get bug reports for (a), we'll go with (a).

Fixed with http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=fbd77b91884962ff2e926458dc0e799f6fe36f4f