Community
Participate
Eclipse IDE
I experience a severe problem with the editor area of the Java perspective. It gets frozen after a random amount of time, with respect to keyboard events. The mouse still works (clicks have effect). In 3.1 the freeze is total (cannot open new files, no effect on any key). In 3.1.1 the freeze is partial (only F-keys, Ctrl, Alt, Del and alike get frozen) and recovers after switching desktops/windows randomly... As a hint: on 3.1.1, if I select an editor tab during this faulty state of Eclipse, sometimes the tab looks disabled (grayed-out), even it's brought in front and I can navigate within it. The only solution to get Eclipse out of this state is to restart it - much like working on windows and not fun at all :( I'm running on GTK+ 2.6.8. Other GTK applications work fine.
3.1.1 isn't released yet -- can you verify the version numbers? What window manager are you using?
3.1.1 = the 3.1.1 milestones available (except for the last which I'm downloading now) The display manager is KDM, "focus follows mouse", "click to raise".
I should also mention that other Eclipse view (package explorer, ant etc.) are working fine. The behaviour I signaled regards only for the editor view. So it's unprobable that it has anything to do with the display manager.
I suspect it has to do with focus follows mouse. See bug 92542. What happens is that if SWT doesn't think the window has focus, key events won't get propagated properly. SWT hasn't submitted for any of the 3.1.1 M-builds yet I don't think so if the behaviour is different this is pretty interesting. To try and track this down, let's try two things: 1. Can you run without focus-follow-mouse? 2. Can you try and see if any of these are what triggers the bad behaviour: - moving the mouse while the code assist or other pop-up is visible - alt-tab'ing between apps - position of the mouse while switching desktops - position of the mouse while using code assist
I can replicate bug 92542 ONLY after switching back and forth the desktop - switching teh window is not enough (after starting Eclipse). I cannot replicate my bug trying the tests at (2). I will try (1) and come back with the answer - it might take several hours. Anyway, I realized that this frozen state is triggered after opening/switching to another file in the editor. No other windows involved. My hunch is that that something odd happens with the focus when switching files in the editor, but it's apparently random. Might be a timing issue. Thanks for taking it seriously.
I've tried to reproduce the bug with a classic focus policy ("click to focus"). I didn't, but then again I haven't had the chance to try it longer. Instead, I maintain my claim that it has something to do with the way the editor tabs are enabled/selected/receive focus after creating a new file (a Java class in my case). I believe it has little to do with the focus policy and other windows, it's an internal Eclipse problem because other views than editor continue to work as normal. The funny thing is that on 3.1.1 only certain keys are lost, not all of them (so I can type letters and delete them with Backspace, but F-keys, Del, Ctrl do not work: for instance I type Ctrl-S but no save operation takes place, but if I press S, I see an S in the edited file. I think this selectivity would make a good starting point in tracking down the cause.
:) This is a replication scenario for 3.1.1 Build id: M20050811-0400. Although I'm not sure if that's an effect of your bug or mine. Take a desktop without windows. Open Eclipse. Open a project with a task and some edited file. Change the priority of the task by editing it directly in the table (you'll see a combo). Click back in the editor. Everything is fine. Now switch once back and forth the desktop. Edit again the priority of the task. Click back in the editor. Nothing works! You'll have to switch again the desktop in order for the editor to regain focus (although it's appearance shows it's active). All this is valid for "focus follows mouse" policy. For "click to focus" policy the bug is not reproduceable. Display manager: kdm (KDE), GTK+: 2.6.8.
...One more thing (I hate the fact that bugzilla doesn't allow message editing): other views than editor STILL work when the editor is frozen, just try the arrow keys (up and down). I hope this helps and I'm waiting for news. Thanks again.
Yeah, just great... the keyboard freeze happens with "click to focus" policy, too! I've obtained the "efect" twice in half an hour. This time it's a partial blindness (only Del, F-keys Ctrl and such don't work). I cannot give a replication recipe... ...is someone reading this?
Have you been using GTK+ 2.6.8 the whole time? I am surprised you are so easily able to get this. I am worried if the fix for this bug, which appears in 2.6.8, makes this problem happen: http://bugzilla.gnome.org/show_bug.cgi?id=109246 Thanks for getting such detailed steps in the focus-follows-mouse case, I haven't yet set up the environment to try and reproduce but I'll get on it.
My log shows following install dates: Sun Apr 17 15:34:50 2005 >>> x11-libs/gtk+-2.6.7 Mon Jul 4 14:41:39 2005 >>> x11-libs/gtk+-2.6.8 As for Eclipse: Wed Jul 6 23:32:46 2005 >>> dev-util/eclipse-sdk-3.1 Tue Jul 19 23:12:26 2005 >>> dev-util/eclipse-sdk-3.0.2 Thu Aug 11 00:37:01 2005 >>> dev-util/eclipse-sdk-3.1.1 I didn't have any problems with Eclipse 3.0... and it's driving me nuts. When debugging, use KDE 3.4, Eclipse 3.1.1 (latest M), GTK+ 2.6.8. The focus policy can be set in Control Center -> Desktop -> Window Behaviour -> Focus. I'm glad to help with any other info.
(If you IRC, irc.freenode.net #eclipse-dev)
OK, I can reproduce the problem with GTK+ 2.8.0 but not with GTK+ 2.6.7, so I do believe this is related to the fix for the above referenced GTK+ bug.
Great, I'm stepping back gtk+ and let you know what happens. Do you have any clue about the partial key "blindness"? I'm afraid there might be two separate issues here :(
I think it's quite likely that's a separate problem, it sounds quite strange.
Created attachment 26318 [details] Proposed patch One obvious solution that seems to work is to only enable the fix for the GTK+ bug on versions that are broken. I remember that we were hesitant to make this fix before, but I think it was because GTK+ 2.6.8 wasn't out yet for us to test, and fears about reintroducing old bugs. Given the severity of this problem, if this fix is good, we should seriously consider pushing this out.
Ok, I believe that after one day of heavy use (2 Eclipse windows, 1 Eclipse Help window) I can say that reverting to GTK 2.6.7 solves all issues. Tell me when the next 3.1.1 M including your patch will be released so I can try it with the newest GTK available. One more hint: with GTK 2.6.8, when I invoked the autocompletion by pressing Ctrl+Space, but changed my mind and switched window/desktop, the popup window would still float over other windows - I had to go back in the Eclipse editor and press Esc to make it disappear. I realized that this behaviour was not normal only after reverting to GTK 2.6.7 :)
Downgrading to major. Though this bug is severe, I don't believe it causes crashes or data loss. This bug first appears in 3.1, so I'm changing the version too. The "partial blindness" can be that all of the key bindings aren't working, but native key behaviour will then assert itself. This means only a very minimal set of keys will be working, such as cut, copy and paste. I talked briefly with Billy about this. My feeling that this area of code is quite brittle and that any change made in the 3.1.1 stream should be avoided if at all possible. However, making this change in the 3.2 stream sounds like a good idea -- the sooner, the better. I'm downloading GTK+ 2.6.8 now to try to assess how bad this problem is.
I have removed the old workaround on GTK+ 2.6.8 or higher in HEAD. Leaving this open for consideration for 3.1.1.
Okay, the problem is bad. Quite bad. I can't figure out how to get back to sane state, and all of the key binding architecture is hosed -- only native bindings are working. This really does need to be fixed for 3.1.1. I've filed "http://bugs.gentoo.org/show_bug.cgi?id=103477" with Gentoo Linux to try to keep them from unmasking GTK+ 2.6.8 and later until Eclipse 3.1.1 is out. I feel that we should -- if we have enough time -- try to ascertain exactly why this problem is happening. And also try to make sure that Owen's changes fix all of the problems our workaround addressed.
Are you telling me that a different pile of garbage work arounds are needed for the latest version of GTK? What a waste of time.
No, the idea is hopefully that we avoid the old garbage work arounds when running under a new version of GTK+.
Off topic, what about the Qt port of SWT?
>No, the idea is hopefully that we avoid the old garbage work arounds when >running under a new version of GTK+. +1
Oops, replication scenario with GTK+ 2.6.7 (!), Eclipse 3.1.1 Build id: M20050811-0400, "focus follows mouse" policy: Take 2 Eclipse windows, of unequal size. Click on an editor tab in one window. Press Alt-Tab so as the mouse is still on the first window when the second is brought in front. Press Alt-Tab again. Try to move the cursor with the arrow keys :) Change the focus again using the mouse and you'll regain control...
Problems like that under GTK+ 2.6.7 are the reason the bug was fixed in GTK+ for 2.6.8. Can you try with the latest 3.2 I-build under 2.6.8 and see if you can find any problems? It includes the fix posted here.
Fixed in the maintenance stream > 20050913 Please open new bugs for remaining focus issues.
*** Bug 109537 has been marked as a duplicate of this bug. ***
eclipse-SDK-M20050914-1235-linux-gtk.tar.gz has a red X as status. Does this mean it doesn't work?
It just means there was a failure in the automated tests. If you click on the X you will see which tests failed. The platform-releng-dev list is where the builds get discussed, in this case see: http://dev.eclipse.org/mhonarc/lists/platform-releng-dev/msg04853.html
I'm having the same problems. Using Eclipse 3.1.1 with CDT. KDE 3.3.2 on Linux 2.6.8-2-686. Both focus-follow-mouse and click-to-focus gives the same symptoms. Any ideas? - Juho Mäkinen
Are you running Debian stable (GTK+ 2.6.4-x from Debian?) They backported the fix from GTK+ 2.6.8 and this breaks Eclipse's version checking.
I have the same problem on Eclipse SDK Version: 3.1.2 Build id: M20060118-1600 running on Windows XP Pro with SP2. It's a big problem and if I can't solve it I just have to go back to 3.0.x :( /Martin
I had exactly the same problem in WinXP SP2 with Eclipse 3.1.1 and 3.1.2. The work-around I found was to click on <Restore Defaults> in Preferences->General->Keys. B.T.W. The only changes I'd made to key settings was these: Ctrl+Tab = Next Editor Ctrl+Shift+Tab = Previous Editory Tab = Indent line But my problem din't occure until long after I made these changes. After I did the <Restore Defaults>, I applied my key-settings changes again. And it haven't yet retriggered the problem.
I've had this problem for many months (more than a year?) and was happy to see that you believed it was solved. I started a fresh installation of Eclipse 3.1.2 with EMF 2.1.2, XSD 2.1.1 and TPTP 4.0.1, WinXp SP1 with numerous fixes. From the old installation I imported the XML file containing the settings for the code formatter and copied the launch profiles. Regretfully the problem occurred again after a week during a debug session. The application paused on a breakpoint, I used the mouse to set the cursor after the dot on an instance variable and pressed CTRL+SPACE. Worked fine the first time, but when I did the same after ALT+TABing away and back, Eclipse had entered this bug mode. Peter Møller Nielsens workaround posted 2006-12-18 08:44 seemes to solve the problem - even while Eclipse had entered the bug mode. I hadn't changed any keys though.
Doug, Peter describes the same problem on Windows XP and a fix that Jens says works on GTK. Billy believes that his patch fixed it but notes that the bug still happens on Debian because they backported some the code that caused the problem without changing the version numbers (!). Do you have any ideas on this one? Jens, are you running Debian?
Steve, I've posted on Linux OS although I'm running Windows XP because I only found the bug described here. If there is a windows equivalent of this bug, please direct me to it. Thanks Jens.
This isn't fixed for me. The only version that works is 3.1.0. Any 3.1 higher than that has this issue. I can trigger the problem within 2 minutes of starting eclipse. This bug is a showstopper for me. Window Manager: Openbox 3.3rc2 Distro: Yes, you guessed it, gentoo Gtk+: 2.8.13 glib: 2.8.6 Perhaps it's my WM, perhaps not. I can replicate this problem on two machines. All the programs are the same versions, except the other machine is amd64, but sitll using 32 bit eclipse. Can anyone suggest a way to debug this, to try to determine what exactly is the problem?
This bug is still available on all our Linux Ubuntu 9.10 systems (64bit standard installation). I can cause a frezze of keyboard with just throw an exception in a gui element of a running java program, started in eclipse. For example runing a loop (eg. for 1-5000) and open a JOptionPane dialog in a thread while loop continues. When this loop ends before the dialog finished an exception will fired and eclipse freeze the keyboard.
This issue persists. I usually encounter it when pressing control, alt, and arrow keys to change desktops. I am running Ubuntu 11.04 with GNOME 2.32.1. I can reactivate keyboard input by minimizing and maximizing Eclipse.
Still the same issue here: Eclipse 3.6.2 Debian 5.0.8 and 6.0.2 Gnome 2.22.3 and 2.30 GTK 2.18.6 and 2.20.1 Glib 2.24.2 and 2.24.2
