Community
Participate
Working Groups
Created attachment 241351 [details] Context menu does not open adjacent to mouse Using Eclipse M6 and GTK3. For some elements right-clicking that element opens the context menu a distance away from the mouse pointer - see attached screen cap. The context menu should always open next to the mouse pointer when invoked by mouse. This behavior is not replicated for those same elements with GTK2.
Can you provide a swt snippet to use for reproducing/testing/fixing the issue? It's pretty hard to work on things that happen sometimes/somewhere.
This happens in JBoss Tools in a view that's using CNF. I should be reproducible in the project explorer when right clicking on a 3rd and then immediately twice on a 4th level child (@Michelle: please confirm/refute). The original steps are reported here: https://issues.jboss.org/browse/JBIDE-16879
I tried out the same actions in Project Explorer view but I was unable to see if the issue was replicated. On JBoss Tools OpenShift Explorer view, when you right-click an item the context menu opens so that the mouse pointer and top left corner of the context menu are in the same location. For the rogue behavior, the top left corner of the context menu is shifter vertically higher that the mouse pointer. It is hard to see if this same behavior occurs in the Project Explorer view because the context menu for all items is so long that the mouse pointer and top left corner of the context menu are rarely in the same location. But I did replicate it within the Server view and within the Git Repositories view for every level under the first level - screen caps added. So right clicking on a 1st level item and then immediately twice on any 2nd+ level item.
Created attachment 241422 [details] Git Repositories view context menu shift for 2nd level child
Created attachment 241423 [details] Git Repositories view context menu shift for 3rd level child
Created attachment 241424 [details] Servers view context menu shift for 4th level child
*** Bug 413899 has been marked as a duplicate of this bug. ***
Is this bug still reproducible with Neon builds?
I am using Neon with org.eclipse.swt 3.105.0.v20151209 and I can still experience this (see attached screenshot: displaced-context-menu.png). But it wont happen always. To reproduce it in the servers view I have to do the following: 1) select an existing server 2) unselect it 3) position mouse so that it's NOT above a server (table item) and open up the context menu Strange enough it will only happen in the 1st invocation of the context menu. It wont on each subsequent one. It also wont happen if the context menu is opened with a server selected.
Created attachment 259074 [details] displaced context menu in Neon swt 20151209-1900
I can reproduce this bug as well in the latest Neon nightly. It's sometimes a bit tricky to nail down, but the most reliable way I've been able to reproduce it is: 1) Open an Eclipse workspace with the EGit "Git repositories" view. 2) Add some git repositories. 3) Browse the list of branches and scroll a bit. 4) Right click a branch. The context menu will appear ~200px higher than the mouse pointer.
I still observe this on 4.7 I20161121-2000 GTK 3.14 (RHEL 7.2). Steps as described: open Git repo view in Java perspective (bottom left corner) expand one repository node right click this repository node (popup appears at right position) right click the "Branches" node (popup appears way too high) Probably this is tree/table related. It looks like to reproduce it in general, first a popup with very big number of elements need to be displayed for a parent tree element, so that it is "wrapped" by GTK (arrows up/down are shown on top/bottom of the popup). Next, the popup for the *child* element with short list of the entries must be shown - and this one seem to be always placed much higher as expected, as if the tree would somehow remember that the previous popup had not enough place to show and added this offset to the next popup location.
Can you come up with swt only snippet for testing ?
(In reply to Alexander Kurtakov from comment #13) > Can you come up with swt only snippet for testing ? No. I've quickly debugged this but I couldn't find anything obvious. The coordinates we receive from GTK in org.eclipse.swt.widgets.Control.gtk_event_after(long, long) and pass to org.eclipse.swt.widgets.Control.showMenu(int, int) are OK and identical in both cases (first click where the popup is mis-placed and second click where it is shown properly). What really surprised me is the fact that I can't see *any* call to the setBounds() or setLocation() neither on Control not on Canvas - is this handled entirely in the native GTK code, or how do we position the popups?
(In reply to Alexander Kurtakov from comment #13) > Can you come up with swt only snippet for testing ? Alexander, can it be similar to bug 509514? The location is evaluated wrong for a first invocation of the popup on the tree, so probably we fail to say GTK3 which "tree child" should be used to calculate the popup location?
(In reply to Andrey Loskutov from comment #15) > (In reply to Alexander Kurtakov from comment #13) > > Can you come up with swt only snippet for testing ? > > Alexander, can it be similar to bug 509514? The location is evaluated wrong > for a first invocation of the popup on the tree, so probably we fail to say > GTK3 which "tree child" should be used to calculate the popup location? Could be. I haven't found time to investigate this one yet.
Hi, This problem seems to be fixed by my fix in Bug 505992 , however only in Wayland. The problem still seems to persist in X11. My suggestion is that this is more-or-less fixed once my fix has been merged, as we can now recommend using Wayland instead.
(In reply to Ian Pun from comment #17) > Hi, > > This problem seems to be fixed by my fix in Bug 505992 , however only in > Wayland. The problem still seems to persist in X11. My suggestion is that > this is more-or-less fixed once my fix has been merged, as we can now > recommend using Wayland instead. Any ideas why it doesn't work properly on x11?
Btw, I found a way to reproduce this in a simple child Eclipse. (Gtk3.22, Fedora25. Today's SWT with @Ian gtk_popup_menu deprecation patch applied). 1) Open Problem View. Have at least 1 problem. 2) Move Problem View down, such that menu is shown *above* pointer. 2) Expand "errors". 3) Right "click Errors" 4) Right click just below errors on a child. (menu goes away) 5) Right click on first child. Sometimes the issue occurs right away, sometimes on 2nd/3rd right click on child.
Created attachment 268985 [details] Menu shows above if ProblemView is small and click parent then child
*** Bug 498438 has been marked as a duplicate of this bug. ***
@SWT (Red Hat) team: can we add this to the 4.8 plan? This is really annoying issue. If you need a RH ticket to get some time working on it, I can create it via our RH customer support, it is perfectly reproducible on RHEL 7.2.
(In reply to Andrey Loskutov from comment #22) > @SWT (Red Hat) team: can we add this to the 4.8 plan? This is really > annoying issue. If you need a RH ticket to get some time working on it, I > can create it via our RH customer support, it is perfectly reproducible on > RHEL 7.2. Assuming you face it with rhscl eclipse please open tickets . It helps in many ways :).
(In reply to Alexander Kurtakov from comment #23) > (In reply to Andrey Loskutov from comment #22) > > @SWT (Red Hat) team: can we add this to the 4.8 plan? This is really > > annoying issue. If you need a RH ticket to get some time working on it, I > > can create it via our RH customer support, it is perfectly reproducible on > > RHEL 7.2. > > Assuming you face it with rhscl eclipse please open tickets . It helps in > many ways :). It took some time to get through our bureaucracy, but here is it: https://access.redhat.com/support/cases/#/case/01912387
(In reply to Andrey Loskutov from comment #24) > (In reply to Alexander Kurtakov from comment #23) > > (In reply to Andrey Loskutov from comment #22) > > Assuming you face it with rhscl eclipse please open tickets . It helps in > > many ways :). > > It took some time to get through our bureaucracy, but here is it: > https://access.redhat.com/support/cases/#/case/01912387 Currently it is stuck at the first level RH support with usual irrelevant questions. Can someone from RH SWT team please confirm this issue in RH tracker?
(In reply to Andrey Loskutov from comment #25) > (In reply to Andrey Loskutov from comment #24) > > (In reply to Alexander Kurtakov from comment #23) > > > (In reply to Andrey Loskutov from comment #22) > > > Assuming you face it with rhscl eclipse please open tickets . It helps in > > > many ways :). > > > > It took some time to get through our bureaucracy, but here is it: > > https://access.redhat.com/support/cases/#/case/01912387 > > Currently it is stuck at the first level RH support with usual irrelevant > questions. Can someone from RH SWT team please confirm this issue in RH > tracker? It's in our RH bugzilla now.
Please check if bug 526083 is related - it provides an example and gives a hint to the possible root cause.
Just out of curiosity, do you experience this bug on RHEL 7.4 as well?
(In reply to Eric Williams from comment #28) > Just out of curiosity, do you experience this bug on RHEL 7.4 as well? The bug is still reproducible with 4.7.2, 4.8.0 M5 / RHEL 7.2 (gtk3-3.14.13-16.el7.x86_64), 7.4 (gtk3-3.22.10-4.el7.x86_64).
Renaming the title because we have practically every GTK3 version in there. Some further investigation has yielded that the wrong Menu pops up all together, something I didn't notice before. Following the steps in comment 19, after the bug is reproduced you'll notice that the wrong Menu is being opened. For example: 1) Right click Errors 2) Right click the first child of Errors 3) Right click Errors again You'll notice after 3) that the menu that has popped up is not that of Errors, but its child. This continues to happen (i.e. right clicking the child of Errors shows the menu for Errors, etc.) In between the button click event and Menu._setVisible() being called, roughly 50-60 MenuItems are created. I can't help but wonder if there is some sort of timing/caching issue here. I'll continue to investigate.
(In reply to Eric Williams from comment #30) > Renaming the title because we have practically every GTK3 version in there. > > Some further investigation has yielded that the wrong Menu pops up all > together, something I didn't notice before. Following the steps in comment > 19, after the bug is reproduced you'll notice that the wrong Menu is being > opened. For example: > > 1) Right click Errors > 2) Right click the first child of Errors > 3) Right click Errors again > > You'll notice after 3) that the menu that has popped up is not that of > Errors, but its child. This continues to happen (i.e. right clicking the > child of Errors shows the menu for Errors, etc.) > > In between the button click event and Menu._setVisible() being called, > roughly 50-60 MenuItems are created. I can't help but wonder if there is > some sort of timing/caching issue here. I'll continue to investigate. Update on this issue: I have a fix for the incorrect Menu content problem. The issue only happened on GTK3.22 -- and is separate from the positioning problem. I am continuing to investigate a fix for the positioning issues.
Gerrit change https://git.eclipse.org/r/118221 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=00a9fb75ecf39cbc011c4cba979324660c6b44eb
(In reply to Eclipse Genie from comment #32) > Gerrit change https://git.eclipse.org/r/118221 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=00a9fb75ecf39cbc011c4cba979324660c6b44eb I've merged the fix for the incorrect menu content on GTK3.22+. I am keeping this bug open for the positioning issues.
New Gerrit change created: https://git.eclipse.org/r/118383
Gerrit change https://git.eclipse.org/r/118383 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=272bf0d8ebce8f12e9bb0de2c389d3a18d319afb
(In reply to Eclipse Genie from comment #35) > Gerrit change https://git.eclipse.org/r/118383 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=272bf0d8ebce8f12e9bb0de2c389d3a18d319afb The fix for the positioning issue is in master. As stated in the commit message: the bug is fixed for GTK3.22. Versions less than GTK3.22 will still have the bug, as these menus use the old-style GtkMenu API which is quite different from GTK3.22 and also deprecated. 3.22 is the stable release of GTK3 so the effort spent to fix 3.22- deprecated functions is not worth it.
(In reply to Andrey Loskutov from comment #29) > (In reply to Eric Williams from comment #28) > > Just out of curiosity, do you experience this bug on RHEL 7.4 as well? > > The bug is still reproducible with 4.7.2, 4.8.0 M5 / RHEL 7.2 > (gtk3-3.14.13-16.el7.x86_64), 7.4 (gtk3-3.22.10-4.el7.x86_64). Andrey, please confirm the fix on RHEL 7.4 using tomorrow's I-build.
Verified in I20180305-2000.
*** Bug 493520 has been marked as a duplicate of this bug. ***
*** Bug 82404 has been marked as a duplicate of this bug. ***
*** Bug 480371 has been marked as a duplicate of this bug. ***
*** Bug 381600 has been marked as a duplicate of this bug. ***
