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

Bug 82404

Summary: Context menus appear far from where the user clicked
Product: [Eclipse Project] Platform Reporter: Billy Biggs <billy.biggs>
Component: SWTAssignee: Bogdan Gheorghe <gheorghe>
Status: CLOSED DUPLICATE QA Contact:
Severity: normal    
Priority: P3 CC: billy.biggs, cocoakevin, eclipse.felipe, ericwill, ipun, overholt, snorthov
Version: 3.1Keywords: triaged
Target Milestone: ---   
Hardware: PC   
OS: Linux-GTK   
Whiteboard:

Description Billy Biggs CLA 2005-01-07 16:35:27 EST
The context menus in Eclipse do a lot of work in their SWT.Show handler.  By the
time the menu goes to pop up, the mouse cursor may have moved far from where the
user clicked.  It would be better to use the cursor position of the original
click.  I can reproduce this problem on both Windows and Linux-GTK+.

The following is a trivial patch to fix the problem but I am not sure yet if it
has any side effects (can you do setVisible(false);setVisible(true); multiple
times on menus?).

Index: Eclipse SWT/gtk/org/eclipse/swt/widgets/Menu.java
===================================================================
RCS file: /home/eclipse/org.eclipse.swt/Eclipse
SWT/gtk/org/eclipse/swt/widgets/Menu.java,v
retrieving revision 1.62
diff -u -r1.62 Menu.java
--- Eclipse SWT/gtk/org/eclipse/swt/widgets/Menu.java   16 Dec 2004 21:47:44
-0000      1.62
+++ Eclipse SWT/gtk/org/eclipse/swt/widgets/Menu.java   7 Jan 2005 21:29:39 -0000
@@ -866,6 +866,9 @@
        checkWidget();
        if ((style & (SWT.BAR | SWT.DROP_DOWN)) != 0) return;
        if (visible) {
+               if (!hasLocation) {
+                       setLocation (display.getCursorLocation());
+               }
                display.addPopup (this);
        } else {
                display.removePopup (this);
Comment 1 Billy Biggs CLA 2005-02-09 21:22:03 EST
CC'ing Steve to get his opinion.
Comment 2 Steve Northover CLA 2005-02-10 09:28:52 EST
You have the right idea but I'm not sure we can use/should use the public 
API.  The problem is that we don't run the menu right away in setVisible().  
We need to check with Felipe as to why we need to do this.  For example, on 
Windows, setVisible() ran a modal loop leading to non-portable code.  We had 
to defer it to the event loop.  GTK doesn't run the loop so I wonder why we 
are doing it.
Comment 3 Billy Biggs CLA 2005-04-18 23:40:36 EDT
It would be nice to get this change in for 3.1 as I noticed it again.  Felipe,
do you know why we don't just show the menu like Steve suggested?
Comment 4 Felipe Heidrich CLA 2005-04-19 12:00:50 EDT
Billy, it doesn't look right. Pls, come see me for details.

Steve, it is a long history. It all started back in Boris' days...Basically, 
we couldn't fire show menu in button press cause at that point the selection 
(in a tree) was not updated yet. So we changed to do the work in event after, 
then bug 37428 came along. We needed code in keydown to stop the system menu 
(in entry, etc) when a user menu is install, so we had to run show menu in 
button press to be able to stop the system menu, but we could not bring the 
menu up at point. The solution was the import the display addpopup, runpop 
framework from win32 to gtk... and all worked fine ever after. (I'm pretty 
sure I forgot some small details of this history like crashes, GPS, and hangs. 
Really, there is no happy ends.)

Comment 5 Eric Williams CLA 2016-08-18 16:35:23 EDT
Ian, this might be relevant to your menu bug.
Comment 6 Ian Pun CLA 2017-07-26 11:38:52 EDT
there has been some updates to how menus are drawn (as of deprecating gtk_menu_popup() from Bug 505992 ). I will follow up on this if this is relevant still in a week.
Comment 7 Eric Williams CLA 2018-03-20 13:24:50 EDT

*** This bug has been marked as a duplicate of bug 431423 ***