Bug 509947 - [win32] Rollover tooltip on TreeItem of non-focused shell drawn at wrong place
Summary: [win32] Rollover tooltip on TreeItem of non-focused shell drawn at wrong place
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 4.7   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: 4.7 M6   Edit
Assignee: Markus Keller CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 491627
  Show dependency tree
 
Reported: 2017-01-04 13:33 EST by Markus Keller CLA
Modified: 2017-02-01 14:28 EST (History)
5 users (show)

See Also:


Attachments
Screenshot (86.99 KB, image/png)
2017-01-04 13:33 EST, Markus Keller CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
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