Bugzilla – Full Text Bug Listing
| Summary: | [linux][mac] tooltip overlaps with context menu | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Steffen Pingel <steffen.pingel> | ||||
| Component: | Mylyn | Assignee: | Project Inbox <mylyn-triaged> | ||||
| Status: | CLOSED MOVED | QA Contact: | |||||
| Severity: | minor | ||||||
| Priority: | P4 | CC: | eclipse-bugs, tom.schindl | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Steffen Pingel
Can't reproduce on Windows, can reproduce on Windows and Mac. On Mac it appears under the tooltip. I rarely see this bug but it sometime hit (I haven't figured out the pattern, yet). The explanation I have is that SWT sometimes sends a mouseHover() event after the mouseDown() event that trigger the context menu. Is there a way to check if the currently active shell is a context menu (and suppress the tooltip in that case)? I don't remember seeing this before the tooltip refactoring from bug 166406. Created attachment 72619 [details]
rollback to old implementation (see comment)
This patch rollbacks the TaskListToolTipHandler to revision 1.40 for testing. I was able to reproduce the tooltip overlaying the context menu with this patch applied so I suspect that this has been around for a while but was never reported.
Next step could be to try to roll back change for multimonitor support... I don't think that is going to help since that was related to positioning only. This seems to be related to the order of the events, please see comment 2. Steffen: I assume that this patch is not needed given the one on bug 194519? Btw, if not for your filing this bug we may not have realized what was causing the VM crash. It was very hard to diagnose because 4 shells had to be up at the same time (the tooltip one being the problematic one the VM was likely lost a reference too). (In reply to comment #7) > Steffen: I assume that this patch is not needed given the one on bug 194519? No, I just posted it so we can debug this problem better or in case we would not be able to find a fix for bug 194519. (In reply to comment #8) > Btw, if not for your filing this bug we may not have realized what was causing > the VM crash. It was very hard to diagnose because 4 shells had to be up at the > same time (the tooltip one being the problematic one the VM was likely lost a > reference too). It's great that you were able to diagnose it in time! I would not have expected the refactoring for bug 166406 to cause such a regression. Me neither! Any one of us could have done this, because our last-resort parachute is usually the VM and its static type checking and exception handling. This time that parachute had a big hole in it. (In reply to comment #10) > This time that parachute had a big hole in it. Hey! The classic parachute design actually used a hole to make it more stable. :-) Steffen: we done here? I wish we were but the bug is still there. I haven't had any luck finding a way to check if a context menu is currently being displayed to avoid showing the tooltip in that case. Does anyone know how to do that? (In reply to comment #13) > I haven't had any luck finding a way to check if a context menu is currently > being displayed to avoid showing the tooltip in that case. Does anyone know how > to do that? How about to try JFace tooltip support? (In reply to comment #14) > How about to try JFace tooltip support? Given that we dropped Eclipse 3.2 support (?) we could investigate extending the JFace ToolTip class. Related: bug 196109 +1 for new 3.3 JFace tooltip support, I've been waiting for us to move to that and it looks like we have all the freedom to draw components that we will need. BTW, I have also seen a tooltip overlapping the context menu in the Java editor. The only difference was that the tooltip disappeared quickly whereas the task list tooltip sticks around as long as the context menu is open. Using JFace tooltips will most likely fix that. It seems like JFace tooltips are bound to the mouse pointer location and will prevent from improving positioning of Task List tooltip bug 189313 Maybe Tom could comment on that. Well the default implementation is like this but you are free to calculate the position your own see Tooltip#getLocation(Point, Event) (In reply to comment #18) > BTW, I have also seen a tooltip overlapping the context menu in the Java editor. > The only difference was that the tooltip disappeared quickly whereas the task > list tooltip sticks around as long as the context menu is open. Using JFace > tooltips will most likely fix that. This is still a problem even with a JFace ToolTip based implementation. Just noticed on Windows XP, that tooltip is activated from a background Workbench window overlapped by some other active application window (e.g. not maximized web browser) and tooltip shown on top of that active application. (In reply to comment #21) > (In reply to comment #18) > > BTW, I have also seen a tooltip overlapping the context menu in the Java editor. > > The only difference was that the tooltip disappeared quickly whereas the task > > list tooltip sticks around as long as the context menu is open. Using JFace > > tooltips will most likely fix that. > > This is still a problem even with a JFace ToolTip based implementation. > What version of Eclipse are you using. I have fixed a ToolTip hide bug with 3.4M5 (see bug 195137). *** Bug 244691 has been marked as a duplicate of this bug. *** I have seen this on Linux and Mac on Eclipse 3.3 and 3.4. On Linux less frequently with 3.4 but bug 244691 indicates that the problem is still around on Linux. Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn |