Community
Participate
Working Groups
Created attachment 98666 [details] Snippet demonstrating the described behaviour Build ID: I20080502-0100 Whenever a DefaultToolTip is created that exceeds the screen's boundaries, the tool tip is not displayed correctly, it rather flickers once and is dismissed immediately. I've attached a short snippet demonstrating this. Seen on Linux GTK (Ubuntu 8.04, Gnome 2.22.1, GTK+ 2.12.9), Eclipse 3.4M4+ (can't remember exactly when this was introduced; I am currently working with 3.4M7).
..Doing some investigation on this issue, I've found out the following so far: the TooltipHideListener in org.eclipse.jface.window.Tooltip gets an SWT.MouseExit event immediately after the tooltip has been displayed (after its location had been corrected in fixupDisplayBounds). This must have sth to do with the relocation, as it does not occur when the tool tip does not need relocation (does not exceed the display bounds), neither does it happen when respectDisplayBounds is set to false.
Investigation continued (without really going into the depths of the implementation and tracking this down entirely..): As mentioned before, the TooltipHideListener gets sent an SWT.MouseExit event, containing the tooltip's shell as the control. This is because the relocation moves the tooltip underneath the mouse pointer, so that the mouse pointer actually leaves the underlying control's area. The event handler than modifies the control's (in this case, the tooltip's shell's) bounds, checks whether the mouse pointer is contained within these bounds (why is that modification necessary?), finds out it isn't, and finally hides the tooltip immediately, which causes the flicker effect. A slight modification to ToolTip.yShift could partially solve this: in case yShift is initialized as 1 instead of 0, the tooltip is shifted one pixel below the moise pointer, which subsequently does not hit the tooltip in case it is relocated. This only fails when the tooltip is displayed at the lower right edge of the display, so that it needs relocation to the left and up (inevitably hitting the mouse pointer again).
Addition: this issue also happens in viewers with tooltip support, when having a tooltip displayed that hits the right display border. As above, this could possibly be fixed (or even almost fixed) by initializing ColumnViewerToolTipSupport.DEFAULT_SHIFT_Y with 1 instead of 0 (same effect as above).
(In reply to comment #2) > Investigation continued (without really going into the depths of the > implementation and tracking this down entirely..): > > As mentioned before, the TooltipHideListener gets sent an SWT.MouseExit event, > containing the tooltip's shell as the control. This is because the relocation > moves the tooltip underneath the mouse pointer, so that the mouse pointer > actually leaves the underlying control's area. The event handler than modifies > the control's (in this case, the tooltip's shell's) bounds, checks whether the > mouse pointer is contained within these bounds (why is that modification > necessary?), finds out it isn't, and finally hides the tooltip immediately, > which causes the flicker effect. Good question but this makes sense maybe if the tooltip has no hide delay. I just tried with SWT-Tooltips and they don't show such a behaviour (if the mouse leaves the tooltip it is still shown) so maybe we should add a configuration option which disables this feature or maybe we should only turn this on when the ToolTip has no hide-delay? What I don't fully understand now is why we are getting a MouseExit event because after all the relocation stuff happens before the tooltip is shown. Karsten could you give the following patch a try? It's just a wild guess because I don't know why the MouseExit can happen on a not shown shell.
Created attachment 99608 [details] Patch
(In reply to comment #4) > [..] > What I don't fully understand now is why we are getting a MouseExit event > because after all the relocation stuff happens before the tooltip is shown. > > Karsten could you give the following patch a try? It's just a wild guess > because I don't know why the MouseExit can happen on a not shown shell. > Tried, but unfortunately with no effect. As far as I was able to debug the behaviour, it doesn't seem to me that the MouseExit happens on a not shown shell. Perhaps I explained this a bit unclear. The precise order of what is happening seems to be as follows: - Mouse pointer enters the area of the control to which the tooltip is attached, and triggers preparation of the tooltip (normally to be shown 3px to the right of the current mouse pointer position); - fixupDisplayBounds is called, relocating the tooltip to the left in order to not exceed the right display border; - the previous step causes the tooltip to appear "under" the mouse pointer, or, in other words, "between" the original control and the moise pointer; - this subsequently causes a MouseExit (actually, the mouse indeed leaves the underlying control's area, as it now enters the tooltip itself due to the tooltip's relocation); note that both the underlying control and the tooltip are visible; - ..and voila! the tooltip is gone, because this check !rect.contains(c.getDisplay().getCursorLocation()) evaluates as true (org.eclipse.jface.window.ToolTip, around line 714.
Created attachment 99632 [details] Patch removing the fudge coordinates I think the problem is that after the tooltip is shown the mouse pointer is in between the fudge coordinates with used to enure we get informed about an MouseExit event. I removed them and on OS-X everything still behaves as it should.
(In reply to comment #7) > [..] > I think the problem is that after the tooltip is shown the mouse pointer is in > between the fudge coordinates with used to enure we get informed about an > MouseExit event. I removed them and on OS-X everything still behaves as it > should. > Yes, that was what I was wondering about in comment #2. Experimenting with this, I had removed these fudge coordinates myself, but wasn't sure whether they had a deeper reason, so I put this aside meanwhile, looking for an alternate way how to fix this. Anyway, without the fudge coordinates, I can confirm the tooltip works as expected. Thank you.
Ok. We already have a bug #164351 we which has more information it looks like win32 is the problematic platform.
multi change because of intenion of stepping back as platform-ui committer
CQ:WIND00290152 @ll, can we get a status report from the Platform.UI team, we've seen this issue using Eclispe 3.7 and would like to see a fix attempt for 3.8 if at all possible... Thanks a lot! :) Helmut
(In reply to comment #11) > CQ:WIND00290152 > @ll, > can we get a status report from the Platform.UI team, we've seen this issue > using Eclispe 3.7 and would like to see a fix attempt for 3.8 if at all > possible... > Thanks a lot! :) > Helmut *ping*, can we get a comment from the UI team please? Thanks a lot !:) Helmut
We have no one looking at this area at the moment, but would consider patches. PW
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag.
