Community
Participate
Working Groups
Sometimes my workbench will grab the mouse pointer and not release it any more, the only recourse is then to kill the workbench. This happens repeatable for linux -gtk versions when i am using PDE, run a runtime workbench, and before the runtime workbench comes up, i open the launch configuration editor This is using eclipse Freeze 2, gtk drop (20020610)
I believe this is fixed in F3. See bug #18629. *** This bug has been marked as a duplicate of 18629 ***
No, it is not a duplicate of this bug. I just verified this with the 20020610 linux gtk drop, and the behaviour on linux seems the same. Note that the launch configuration model dialog window does a *global* input grab, so that i can't use any other applications on my desktop or work with my windowmanager. This is the culprit in this case, since the outer eclipse is obscured by the runtime workbench which can not be moved because of this global input grab
Ok. Boris to investigate.
Additional note: it does a global keyboard grab for the launch configuration window. This is not expected... (eg with just the launch config open, i can select other windows, but no keystrokes will get through there. If i close it, they do)
Is this still happening in F3 (build 20020612)?
Yes, it still happens with the F3 build. The easiest way to reproduce this is to open eclipse on a new workspace, open the java perspective and open the launch editor (running-man -> run...). Keyboard (and sometimes mouse) events only go to the launch editor. It looks like a X global grab is being done instead of an application global (terminology probably wrong, been a while since i did real X programming).
Having worked a bit more with this release, this behaviour is more common for some other dialogs, for example the Java Project properties page, but not the WizardDialog. I can't find out exactly what is causing this different behaviour between the WizardDialog and the LaunchConfigurationDialog classes
*** Bug 20142 has been marked as a duplicate of this bug. ***
The keyboard grab has been happening to me in F3 when Eclipse creates most modal dialogs. My keyboard is essentially disabled until the modal dialog goes away.
I thought we had a fix for this in for F3. This is *definately* a candidate for fixing for F4. Please let me know if this is possible.
*** Bug 20194 has been marked as a duplicate of this bug. ***
*** Bug 20289 has been marked as a duplicate of this bug. ***
Fixed > F3.
If *this* bug is fixed in F3, then you need to re-open bug 20289, because I experienced bug 20289's problem in F3. Update: Just seconds I followed the steps I outlined in bug 20289, AND THEY STILL FAIL. As a result, I am re-opening 20289, since bugzilla won't let me re-open this one.
Sorry, I meant it is going to be fixed in F4 (> F3).
*** Bug 20493 has been marked as a duplicate of this bug. ***
If this is going to be fixed for F4 then can we please mark it as reopened or assigned, instead of resolved fixed, which is just wrong?
The bug is fixed. The latest build (20020617) contains the fix. I believe there is no reason to reopen this bug.
Can it be that the global grab is still done, but released real quick? I still see problems when i have breakpoints at swt callbacks before the dialog window has been completely realized. Then it grabs the mouse globally. If need be, i can give a simple sceneriao, but by setting a breakpoint on LaunchConfigurationDialog.selectionChanged, i can get this behaviour (most of the time) by opening the launch configuration dialog in an inner eclipse. This makes debugging swt callback code in some places impossible. I would almost suggest looking for every global grab in the code and remove them, since they are harmful
The grab is not done by SWT. It happens in the native widget. The problem with putting breakpoints in callbacks is well know and I don't see any way of fixing it. We can not just release all grabs every time a callback happens (e.g. button press). This will affect the behavior of the widget. On Smalltalk, grabs were released when the debugger openned. This was possible, since to whole environment was integrated (single VM). Breakpoints were implemented as exception and by handling those exceptions, it was possible to release all X grabs. As far as I can tell, this is not how breakpoints are done in a Java VM. I am not sure there is any notification for breakpoints.
Looking at the gtk-faq, it has an entry about this kind of question. There is a gtk option "-sync" which is then handled by the gtk init function. How can i pass such an an argument to the swt-gtk implementation? (BTW, since i forgot in my previous comment, i'm running eclipse-20020619)
Hm, after searching for this, i see that this is not posible, since the code in Display.createDisplay calls gtk_init_check with an empty argv array. Would it be possible to pass these arguments for gtk in some generic way, so i could startup eclipse with fe -gtkarg -sync or something like that?
The -sync option will not help. It is used to force X to report errors synchronously, so that stack traces can be printed from the error handlers. It will not affect the grabbing behavior.
So the only way to debug eclipse plugins under gtk would then be to create a special X session for the target eclipse (fe in Xnest or something like that), it seems. I'll see if i can make that work...
*** Bug 20851 has been marked as a duplicate of this bug. ***
To all: As Silenio has indicated, we have done all we can about this. There will be no fix for the remaining cases for R2.0. It's not clear if we even *can* fix them without ending up with the same "nothing is done in callin" style of UI that Swing implements. Marking as later to remind us to revisit the issue post R2.0.
I just went back and tested the GTK2 build from May 21. It doesn't demonstrate this problem. Do we know what we did to introduce this bug?
Nevermind. I'm a dufus. My test case was more subtle than I thought.
It seems what we want to do is call gdk_pointer_ungrab() if gdk_pointer_is_grabbed() at any point where a breakpoint is triggered inside an SWT application. The problem is finding out that a breakpoint was triggered, since the call needs to be executed within the "target" VM (i.e. inside the process being debugged). I see two possible routes, the first maintains encapsulation the second is more clearly feasible: 1) Find a mechanism for triggering an event inside the VM being debugged whenever a berakpoint is hit (and in the handler for that event ungrab the pointer). Ideally Java would give us a way of executing a little snippet of code before suspending on a breakpoint, but I don't see an interface for this. Another possibility might be to connect to "ourselves" using the debug interface and monitor for breakpoint events. 2) Add kludge code to the Eclipse debugger that, upon breaking, asks the target VM to run a little code snippet ungrabing the mouse pointer. This hook could be triggered only when a debugger is started on an Eclipse workspace to avoid a performance penalty for debugging non-SWT applications. I'm guessing this bug also exists in the Motif versions of Eclipse, since presumably it performs mouse grabs for things like DND.
OK, I have a fix for this that seems to work, though I'd appreciate if people who experience this could test it more.
Created attachment 1701 [details] Patch to connect BreakMouseGrab into the JDT
Created attachment 1702 [details] Class for ungrabbing the mouse in SWT/GTK apps when a breakpoint is hit
What this basically does is it gets loaded when the JDIDebugPlugin is loaded and registers itself to watch launches (if this is a windows system, a quick check shuts all this down for performance reasons). When a Java launch is detected, BreakMouseGrab adds hooks for watching if it ever loads org.eclipse.swt.internal.gtk.OS. If the class does get loaded, i.e. an SWT/GTK program is being debugged, BreakMouseGrab exectudes gdk_pointer_ungrab in the target VM, freeing the mouse pointer if it is already grabbed.
The patch is to the debugger, not SWT. Also, the patch calls internal API. A better solution would be for SWT to define a "clean up" method, probably in Display that is implemented on all platforms. For example, on systems where system modality is supported, this needs to be cleared as well. Jared?
Jared and I have been working on this together, though Jared has disappeared for the week. Ideally this functionality could be implemented exclusively within the toolkit. The problem is that Java gives the application being debugged no mechanism for figuring out that it was suspended (i.e. there's no special event triggered in the target VM when you hit a breakpoint), so code on the JDI side of the debug system is probably going to be necessary. It seems fine to do it as a generic "cleanup" extension to the toolkit instead of a custom hack for SWT/GTK. I suspect this problem may occur in Motif as well, though I have not tried to replicate (Motif does appear to grab the mouse pointer less frequently). WRT to system modal dialogues, they should virtually never be used, so I don't know how much of a concern that is, though I suppose it would be just as well to handle it. A more common case might be in GTK once again if the keyboard is grabbed (though that is not as common as a pointer grab, I think).
Seth's debug-grab-releaser is interesting, but it doesn't address the underlying problem, which happens during normal use of Eclipse. The problem is that the mouse pointer is frequently and unnecessarily globally grabbed. This problem is very evident in the CVS Compare viewer. 1. Synchronize with stream on a project which has changes. 2. In the tree view, double click a file to open the compare browser. 3. You get a busy cursor while the file is loaded from CVS (this can take a long time). While the cursor is "busy", the mouse is globally grabbed.
*** Bug 22056 has been marked as a duplicate of this bug. ***
Its bad that we have global mouse grabs, but they only mean horrible death when they occur in such a manner that they don't get undone several seconds later. Having the CVS compare grab the mouse cursor bites, but its only a bump in the road because you get the mouse back several seconds later. When the mouse stays grabbed during debugging it stays grabbed.
Re: Jared's specific bug.... A simple test case showed that the pointer was grabbed on all click event callbacks to an SWT Tree, but when I registered the same callbacks in a simple gtk C program and slept the thread, the pointer was not grabbed. (Debugging this was made extra miserable because I had to use remote debugging). Looking up and down the Java call stack I couldn't find anything wrong. So.... I ran a remote gdb on the remote Java debug target that eclipse was connected to, and after much mucking about and tracing native code throughout GTK I found that the pointer was getting hammered by a call to gdk_pointer_grab in gtk_clist_button_press (in gtkclist.c). Its not immediately obvious to me why a gdk_pointer_grab is being called here, however I bet its for ensuring that button press and button release events are received in pairs. The native C code doesn't see this because it was only listening to button *press* events. X automatically grabs the pointer when a window's event mask is set to receive button press and release events. Because Eclipse registers all callbacks at widget creation time (this is a bad practice btw, GObject signal emissions are very slow, not to mention passing through the JNI barrier... this is generating a lot of needless signal churn) even though I wasn't looking at the release event it had been registered for me. Thus to make them occur in pairs GTK grabbed the mouse pointer to ensure that I heard about the release event after hearing about the press. Nasty. Maybe this is "fixed" in the signal(s) emitted by GtkTreeView. If not, it means we should be doing no work in the signals generated by list clicks. An alternative would be to unregister button release notification for these widgets, thus making the pointer grab unnecessary (and I believe it won't be done in this case).
Created attachment 1803 [details] This short SWT snippet demonstrates the problem for Trees
Is this a problem in a C debugger as well? If not, how do they solve the problem?
If I put a breakpoint in a pop-up menu callback and activate the pop-up menu with the mouse, my mouse AND keyboard are grabbed. So I can't even alt+tab to switch to my host Eclipse and resume the target. I have to change virtual terminals and kill Eclipse from the console.
We should be debugging this problem the same way that a C programmer would and make an SWT FAQ that describes the necessary steps.
From the newsgroup: > How do you debug SWT on Linux? If I set a breakpoint during a native drag > callback, the machine locks up and must be rebooted. There is no way to > step through the code. > BTW, I only have a one Linux machine. The only workaround I've found so far has been to take advantage of X11's networking abilities and make your runtime present itself on a separate display. Your mileage may vary, but it worked well enough to debug some of my own native drag problems. First create a duplicate of your preferred JRE. In the duplicate, rename the "bin/java" binary and put a wrapper script in its place that sets up a DISPLAY variable pointing to another machine (which you've opened up using the xhost command) and then executes the original binary, passing along all of the parameters that Eclipse supplies. Then it's just a matter of adding it to your list of Installed JREs and updating your launcher. Since you're on a Linux system you can get by with symbolic links for 99% of the JRE's contents. #!/bin/sh DISPLAY=MyRemoteMachine:0 export DISPLAY ../original_java $*
Reassigning to GG. We should make a FAQ out of this, using the same idea of a remote connection. It'd be nice to give people a way to do this on the same machine. FH and SSQ were investigating this.
We still need the FAQ about how to remote debug.
*** Bug 89810 has been marked as a duplicate of this bug. ***
*** Bug 94028 has been marked as a duplicate of this bug. ***
This problem is less of an issue now since there are less places in GTK+ where they do a grab (it's not done in GtkTreeView).
Xnest may be used to "jail" the debugged Eclipse into it's own X. Just run: Xnest :1 & export DISPLAY=:1 start favorite X app I'm not sure how it manages grabbed pointers though.
*** Bug 180045 has been marked as a duplicate of this bug. ***
*** Bug 189996 has been marked as a duplicate of this bug. ***
*** Bug 271123 has been marked as a duplicate of this bug. ***
*** Bug 280126 has been marked as a duplicate of this bug. ***
*** Bug 291994 has been marked as a duplicate of this bug. ***
What is the exact symptom of this bug with regards to the mouse pointer. The original description says it "will grab the mouse pointer". Does that mean the mouse pointer won't move when the mouse is moved? I want to check to verify that Bug 291994 should really have been merged with this bug (in that bug the mouse pointer can still move freely, but no windows respond to any mouse clicks). Thanks. Mike Fairbank.
(In reply to comment #57) > What is the exact symptom of this bug with regards to the mouse pointer. The > original description says it "will grab the mouse pointer". Does that mean the > mouse pointer won't move when the mouse is moved? I believe you can still move freely in this (bug's) case. It's been a while since I hit this problem...considering I try to avoid it (since it hangs X ;)). > I want to check to verify that Bug 291994 should really have been merged with > this bug (in that bug the mouse pointer can still move freely, but no windows > respond to any mouse clicks). I am not necessarily convinced that bug is a duplicate of this one either (since JRE differences has worked around the problem). You could test bug 291994 on other operating systems and see what happens in those cases I suppose.
> I am not necessarily convinced that bug is a duplicate of this one either > (since JRE differences has worked around the problem). You could test bug > 291994 on other operating systems and see what happens in those cases I > suppose. I've just checked bug 291994 as you suggested. I used eclipse Build id: 20090619-0625 , java v6 update 11 , windows xp, and I found the bug did not exist on this combination. I'm not sure if that helps, but there you are...
You can pass the VM argument -Dsun.awt.disablegrab=true to prevent this. It's allowed me to debug code with breakpoints inside combo box call-backs. I found the workaround here (http://bugs.sun.com/view_bug.do?bug_id=6714678).
*** Bug 342075 has been marked as a duplicate of this bug. ***
*** Bug 415203 has been marked as a duplicate of this bug. ***
*** Bug 441587 has been marked as a duplicate of this bug. ***
Closing as per last comments.
