Community
Participate
Working Groups
Environment [Mint Linux, Oracle JDK 7, Java EE 4.4.0M7, Additional Plugins: subclipse, counterclockwise] Shortcuts and some keys become unresponsive while working. E.g. CTRL+F, CTRL+SHIFT+R, CTRL+SHIFT+T, CTRL + D, DEBUG shortcuts (F5,F6,F8) Delete key also doesn't work but backspace. The issue first encountered with M6. Then upgraded to M7, but the issue remains same.
I started in a new workspace to see whether something with the old workspace. But issue is still there. Now backspace is not working. And cursor movements are not possible with any arrow key.
Please provide steps to reproduce. I'm using eclipse and it seems to be working fine. Also, can you attach your log from <workspace>/.metadata/.log? You said you tried a new workspace, can you try your new workspace with only Eclipse Java EE (without subclipse or or counterclockwise? PW
Created attachment 243491 [details] .metadata/.log with counterclockwise and subclipse
No particular steps to reproduce. Suddenly happens while working. I'll check whether I can reproduce it without subclipse and counterclockwise. Thanks for the quick response.
Created attachment 243510 [details] reproduced in pure Java EE (Luna M7) I could reproduce the issue a fresh installation + workspace without any plugins installed. But I used my existing projects. Please find the attached log file.
(In reply to Tharaka manawardhana from comment #5) > Created attachment 243510 [details] > reproduced in pure Java EE (Luna M7) Thanks for the log. I haven't been able to reproduce in my environment, and the log has complaints about mylyn and some graphic icon, not related to keys. Could you try launching with the environment variable SWT_GTK3=0 set and reproduce? PW
Same/similar bug as bug 435706 ? Anyway: Version: Luna Release (4.4.0) Build id: 20140612-0600 Linux 3.8.0-42-generic #62~precise1-Ubuntu SMP Wed Jun 4 22:04:18 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux I experience the same bug, very often the Java Editor get stuck and does not respond to the keyboard anymore. Switching to another editor/eclipse tab (e.g. project explorer) and switching back helps. This is very annoying. See my log file I attached in the next comment - but I am not sure if they contain helpful stuff - the moment when the keyboard get stuck nothing is written to the error log.
Created attachment 244606 [details] workspace/.metadata/.log
Did SWT_GTK3=0 not help?
@Thomas I did not yet try SWT_GTK3=0. I will try it the next days and report here if it helped.
SWT_GTK3=0 definitely fixes the problem! I just tried it and no unresponsive keyboard anymore - everything works perfectly!
*** Bug 435706 has been marked as a duplicate of this bug. ***
I can reproduce this 100% of the time. Using Eclipse 4.5-I20150106-0800. Ubuntu 14.04, GTK3 (default in Mars branch) 1. Create a General Project 2. Create a new text file (test.txt) and type some text 3. Ctrl-shift-R to open the Open Resource dialog 4. Press Escape to close it 5. Try to Ctrl-S to save the dirty editor: it doesn't work. Other key combinations also don't work (as mentioned in original comment). I think this is pretty critical for Mars because GTK3 is the default (for all GTK3 versions now).
*** Bug 453068 has been marked as a duplicate of this bug. ***
(In reply to Marc-Andre Laperle from comment #13) > 1. Create a General Project > 2. Create a new text file (test.txt) and type some text > 3. Ctrl-shift-R to open the Open Resource dialog > 4. Press Escape to close it > 5. Try to Ctrl-S to save the dirty editor: it doesn't work. Other key > combinations also don't work (as mentioned in original comment). I too can reproduce this. I notice that all works fine until I open a dialog- I tried with many dialogs, including "Open Resource", "Find/Replace", "Properties, and even "Preferences". The same thing happens each time, and it happens regardless of whether I use their menu buttons or their keyboard shortcuts. The point at which things break is when the new dialog opens. You can even see the "Save" button in the menu bar move from sensitive to insensitive. After having broken itself, in the "File" menu the "Save" item is insensitive, which would explain why Ctrl-S doesn't work. However, "Find" with Ctrl-F is still sensitive in the menu bar but the keyboard shortcut doesn't work. What git repository should I be looking at for these dialogs opening?
(In reply to Jonny Lamb from comment #15) > What git repository should I be looking at for these dialogs opening? For "Open Resource", the class is OpenResourceDialog it's in the org.eclipse.ui.ide project of the eclipse.platform.ui repository (git://git.eclipse.org/gitroot/platform/eclipse.platform.ui.git) There is a useful tool (Alt-shift-F1) to find which class defines a dialog, etc. See https://www.eclipse.org/pde/incubator/spy/ Finding the repository from the class can be a bit trickier. You can use "Import From repository": http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2FwhatsNew%2Fpde_whatsnew.html
*** Bug 462007 has been marked as a duplicate of this bug. ***
*** Bug 462250 has been marked as a duplicate of this bug. ***
(In reply to Jonny Lamb from comment #15) > I too can reproduce this. For some reason I'm having real problems reproducing this now. Is it just here or has there perhaps been another change which could have affected this bug?
(In reply to Jonny Lamb from comment #19) > (In reply to Jonny Lamb from comment #15) > > I too can reproduce this. > > For some reason I'm having real problems reproducing this now. Is it just > here or has there perhaps been another change which could have affected this > bug? I can't reproduce this with the steps from comment 13. However, yesterday I had to switch back to GTK2 because I keep running into this bug. I'll switch back to GTK3 again and try to come up with steps (and hopefully an example program).
(In reply to Jonny Lamb from comment #19) > (In reply to Jonny Lamb from comment #15) > > I too can reproduce this. > > For some reason I'm having real problems reproducing this now. Is it just > here or has there perhaps been another change which could have affected this > bug? It happened to me yesterday about 10 times, in regular coding workflow (using hyperlinks, hovers, call hierarchy, etc). Can yo reproduce this at all after navigating for a few minutes? The steps are not as clear as before but I the problem is definitely not gone. Maybe we should look at adding some debug output to help isolate the issue? I could run a custom built SWT for my daily work if that helps.
*** Bug 458781 has been marked as a duplicate of this bug. ***
(In reply to Marc-Andre Laperle from comment #20) > (In reply to Jonny Lamb from comment #19) > > (In reply to Jonny Lamb from comment #15) > > > I too can reproduce this. > > > > For some reason I'm having real problems reproducing this now. Is it just > > here or has there perhaps been another change which could have affected this > > bug? > > I can't reproduce this with the steps from comment 13. However, yesterday I > had to switch back to GTK2 because I keep running into this bug. I'll switch > back to GTK3 again and try to come up with steps (and hopefully an example > program). I can reproduce it again, sometimes it takes a second or third time but with the same steps I can get it to that state. I'll try to debug a bit to narrow it down.
(In reply to Marc-Andre Laperle from comment #23) > I can reproduce it again, sometimes it takes a second or third time but with > the same steps I can get it to that state. I'll try to debug a bit to narrow > it down. Ah I hit it once today and had to restart Eclipse. I've been looking at other stuff though. I'll get back to this soon and will update here.
Just a little update, I was targeting an older build of Eclipse 4.5 (M6) unknowingly which is why I was able to reproduce it again. But what's interesting is that I can reproduce it with the latest SWT from the master branch combined with Eclipse 4.5M6. I will continue pursuing in that direction because it might be exposing a the real issue in SWT. What I see so far is that the StyledText widget is not getting a SWT.FocusIn event when is stops working (even when Alt-tabbing). Because there is no FocusIn, the key binding logic doesn't operate correctly (KeyBindingDispatcher, BindingTableManager, etc).
*** Bug 464176 has been marked as a duplicate of this bug. ***
Created attachment 252745 [details] SWTBot test project I have made a swtbot test for this because I found it tedious to reproduce. Maybe it will help others to reproduce the issue. 1. Import the attached plug-in 2. Open the integration.target file, Set as Target Platform (top right corner of the editor). This will download the dependencies (SWTBot, latest Eclipse integration build) and compile your code against it. 3. Right-click on TestKeyboardBug.java, Debug As, Plug-in test. This should create a project, create a text file an open it. 4. Once the text file is opened, type some text and press Ctrl-shift-R to open a dialog (Open Resources). 5. Press escape to close the dialog. The keyboard shortcuts should not work anymore. If you need to change back your target platform, you can go in preferences, Plug-in Development, Target Platform and choose Running Platform (the default). BTW from what I tested, it seems that I can reproduce this more consistently with GTK 3.10.8 (as opposed to GTK 3.12.2 which is the version of Ubuntu 14.10)
*** Bug 465463 has been marked as a duplicate of this bug. ***
Raising severity to blocker because I don't think we can ship with such a big problem, especially if gtk 3 is the default.
What's I'm seeing looks very much like https://bugzilla.gnome.org/show_bug.cgi?id=677329 In gdkeventsource.c:handle_focus_change(), toplevel->has_pointer_focus is set to true and never set back to false again. Because of that, the HAS_FOCUS macro always evaluates to true which means gdk/gtk won't generate a GDK_FOCUS_CHANGE event anymore which also means no SWT.FocusIn/SWT.FocusOut anymore. There was a fix applied to xserver to fix part of https://bugzilla.gnome.org/show_bug.cgi?id=677329 but unfortunately, it doesn't fix this issue. However, there is a workaround: setting the environment variable GDK_CORE_DEVICE_EVENTS=1. I cannot reproduce the bug with this workaround. According to https://bugzilla.gnome.org/show_bug.cgi?id=677329#c14, the downside would be no tablet/touchscreen support. Perhaps it's a reasonable workaround until the real issue is fixed. So Eclipse could set this in the launcher but one downside is that anything that uses SWT without the launcher will not get this workaround. BTW, I've been trying to make a sample program in pure SWT or even JFace but so far I could only reproduce it in the workbench. Perhaps one approach would be to make a program in pure GTK and then go further in the GTK/xserver debugging.
(In reply to Marc-Andre Laperle from comment #27) > Created attachment 252745 [details] > SWTBot test project > > I have made a swtbot test for this because I found it tedious to reproduce. > Maybe it will help others to reproduce the issue. > > 1. Import the attached plug-in > 2. Open the integration.target file, Set as Target Platform (top right > corner of the editor). This will download the dependencies (SWTBot, latest > Eclipse integration build) and compile your code against it. > 3. Right-click on TestKeyboardBug.java, Debug As, Plug-in test. This should > create a project, create a text file an open it. > 4. Once the text file is opened, type some text and press Ctrl-shift-R to > open a dialog (Open Resources). > 5. Press escape to close the dialog. The keyboard shortcuts should not work > anymore. > > If you need to change back your target platform, you can go in preferences, > Plug-in Development, Target Platform and choose Running Platform (the > default). > > BTW from what I tested, it seems that I can reproduce this more consistently > with GTK 3.10.8 (as opposed to GTK 3.12.2 which is the version of Ubuntu > 14.10) I tried these steps on Ubuntu 14.04 with GTK 3.10.8 multiple times but wasn't able to reproduce the problem at all, not sure what's wrong exactly...
BTW, thanks for your persistent and excellent sleuthing on this bug Marc-Andre! :-) I'm curious whether disabling UBUNTU_MENUPROXY makes any difference, but on second thought, it looks like the bug has been encountered by people who're not on Ubuntu as well.
(In reply to Arun Thondapu from comment #31) > I tried these steps on Ubuntu 14.04 with GTK 3.10.8 multiple times but > wasn't able to reproduce the problem at all, not sure what's wrong exactly... There might be timing involved here. I can reproduce this just sometimes on my non-vm Ubuntu but in a specific VM, I can reproduce it very consistently. (In reply to Arun Thondapu from comment #32) > I'm curious whether disabling UBUNTU_MENUPROXY makes any difference, but on > second thought, it looks like the bug has been encountered by people who're > not on Ubuntu as well. If that helps: I always disable it when I reproduce and investigate bug. I also have it disabled in my non-VM Ubuntu because I use metacity/gnome-flashback (I found compiz/unity too unstable).
New Gerrit change created: https://git.eclipse.org/r/46973
(In reply to Eclipse Genie from comment #34) > New Gerrit change created: https://git.eclipse.org/r/46973 Here's a patch that sets GDK_CORE_DEVICE_EVENTS=1 in the launcher when running GTK3. It would be best to fix the root issue, most likely in GTK or X server but we would still need a work around for older versions in Eclipse. I think that setting GDK_CORE_DEVICE_EVENTS is probably as good as it gets for a work around.
(In reply to Marc-Andre Laperle from comment #35) > (In reply to Eclipse Genie from comment #34) > > New Gerrit change created: https://git.eclipse.org/r/46973 > > Here's a patch that sets GDK_CORE_DEVICE_EVENTS=1 in the launcher when > running GTK3. It would be best to fix the root issue, most likely in GTK or > X server but we would still need a work around for older versions in > Eclipse. I think that setting GDK_CORE_DEVICE_EVENTS is probably as good as > it gets for a work around. Can this be done programatically ? It would be nice to do it in swt for all swt apps.
(In reply to Alexander Kurtakov from comment #36) > Can this be done programatically ? It would be nice to do it in swt for all > swt apps. There's probably a nicer way in Java to do this but you could do some kind of OS.g_setenv("GDK_CORE_DEVICE_EVENTS", "1"); (ignoring the fact those strings will need to be built properly) somewhere early on in SWT.
(In reply to Jonny Lamb from comment #37) > (In reply to Alexander Kurtakov from comment #36) > > Can this be done programatically ? It would be nice to do it in swt for all > > swt apps. > > There's probably a nicer way in Java to do this but you could do some kind > of OS.g_setenv("GDK_CORE_DEVICE_EVENTS", "1"); (ignoring the fact those > strings will need to be built properly) somewhere early on in SWT. I did not do that because the documentation says this function is not thread safe and recommends to do it as early as possible. If we were to do this in Java code, I think a non-UI thread could call this at that point including other Java threads.
*** Bug 440355 has been marked as a duplicate of this bug. ***
*** Bug 466493 has been marked as a duplicate of this bug. ***
*** Bug 442390 has been marked as a duplicate of this bug. ***
(In reply to Marc-Andre Laperle from comment #35) > (In reply to Eclipse Genie from comment #34) > > New Gerrit change created: https://git.eclipse.org/r/46973 > > Here's a patch that sets GDK_CORE_DEVICE_EVENTS=1 in the launcher when > running GTK3. It would be best to fix the root issue, most likely in GTK or > X server but we would still need a work around for older versions in > Eclipse. I think that setting GDK_CORE_DEVICE_EVENTS is probably as good as > it gets for a work around. Thanks for the patch Marc-Andre! I agree that the real problem needs to be fixed in GTK3 or Xinput2 and the best we can do for Eclipse is to have the workaround enabled in the launcher. Regarding other SWT applications, I've no idea if anyone has actually seen the problem outside Eclipse, I think it would be a good idea to add this workaround to the 'readme' document for Mars under the "Known Issues with SWT" section. I'll go ahead and commit the above patch and rebuild the launcher binaries before the next I-build so that the workaround gets reasonably tested before the release is shipped. Marc-Andre, just to confirm, I'm assuming disabling Xinput2 handling and falling back to legacy GTK+ input handling via the suggested workaround doesn't cause any other problems or regressions as per your testing?
(In reply to Arun Thondapu from comment #42) > Marc-Andre, just to confirm, I'm assuming disabling Xinput2 handling and > falling back to legacy GTK+ input handling via the suggested workaround > doesn't cause any other problems or regressions as per your testing? That's correct. I have been using the workaround (via a launch script) for a few days without seeing the bug or noticing any regressions from it. Of course, additional testing will be greatly appreciated once it's in an integration build.
My experience with the workarounds are very positive: I was starting eclipse with following workaround for a few month now (via a launcher script): SWT_GTK3=0 UBUNTU_MENUPROXY=0 eclipse I did not see the issue occure again :) Since two weeks I now switched to GDK_CORE_DEVICE_EVENTS=1 eclipse and also did not see the issue again as well :) It seems for me it fixed the issue - I am working with eclipse every day.
(In reply to Marc-Andre Laperle from comment #43) > (In reply to Arun Thondapu from comment #42) > > Marc-Andre, just to confirm, I'm assuming disabling Xinput2 handling and > > falling back to legacy GTK+ input handling via the suggested workaround > > doesn't cause any other problems or regressions as per your testing? > > That's correct. I have been using the workaround (via a launch script) for a > few days without seeing the bug or noticing any regressions from it. Of > course, additional testing will be greatly appreciated once it's in an > integration build. Sounds good. I'll get this into tonight's I-build then, did you check my comment on gerrit... nothing major but will commit after you respond, thanks!
(In reply to Arun Thondapu from comment #45) > Sounds good. I'll get this into tonight's I-build then, did you check my > comment on gerrit... nothing major but will commit after you respond, thanks! I updated the patch, thanks! (sorry for the delay)
Gerrit change https://git.eclipse.org/r/46973 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=0cf5caa1400231038c44e978101f7c51517b5cd4
(In reply to Eclipse Genie from comment #47) > Gerrit change https://git.eclipse.org/r/46973 was merged to [master]. > Commit: > http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/ > ?id=0cf5caa1400231038c44e978101f7c51517b5cd4 The launcher binaries have been rebuilt and committed to git via https://git.eclipse.org/c/equinox/rt.equinox.binaries.git/commit/?id=076a7eb2180ce3ce9add346935a64a614d0a52b3 The fix (workaround) should be available in the next I-build (I20150508-2000). Everyone running into this bug is encouraged to download and try this (or any subsequent) I-build and confirm that the problem is resolved. Thanks all for the bug reports and specially to Marc-Andre for tracing the culprit and finding the workaround!!
*** Bug 465139 has been marked as a duplicate of this bug. ***
Using 4.5.0.I20150511-2130 for 1/2 a day now and I have not lost keybindings so far. Before that I took a few minutes to loose them.
*** Bug 441939 has been marked as a duplicate of this bug. ***
*** Bug 470005 has been marked as a duplicate of this bug. ***
Yep. This seems fixed to me, too. Nice work.
FYIW, *still* suffering from this issue with Eclipse 2020-03 (4.15.0) running on stock Ubuntu 20.04 (GNOME). In this instance, it was just the CTRL key that was no longer working, so CTRL+LEFT/CTRL+RIGHT (cursor keys), which I use all the time to navigate in the editor, were a no-op; plain LEFT/RIGHT were OK. I've definitely had a number of variations of this issue, eg: with the BACKSPACE key. My usual "workaround" is to restart Eclipse; which is rather disruptive to workflow! Thankfully I found a *really* surprising workaround that worked in this instance: https://stackoverflow.com/a/10841915/645016 In light of this, I think this bug should be re-opened or perhaps a new one raised?
(In reply to Christian Sarrasin from comment #54) > FYIW, *still* suffering from this issue with Eclipse 2020-03 (4.15.0) > running on stock Ubuntu 20.04 (GNOME). > > In this instance, it was just the CTRL key that was no longer working, so > CTRL+LEFT/CTRL+RIGHT (cursor keys), which I use all the time to navigate in > the editor, were a no-op; plain LEFT/RIGHT were OK. I've definitely had a > number of variations of this issue, eg: with the BACKSPACE key. My usual > "workaround" is to restart Eclipse; which is rather disruptive to workflow! > > Thankfully I found a *really* surprising workaround that worked in this > instance: https://stackoverflow.com/a/10841915/645016 > > In light of this, I think this bug should be re-opened or perhaps a new one > raised? New one please. I don't see such problems on RHEL 7.4, it works for me out of the box. Please attach info about your configuration (your env. variables and swt section from Help -> About -> Installation Details -> Configuration).
It's possible that the workaround I had put (GDK_CORE_DEVICE_EVENTS=1) doesn't work anymore in GTK 3.24 (Ubuntu 20.04) since it did look like it was a legacy code path that we were enabling with the work around. For the new bugzilla, I would recommend going through my comments to retrace if it's the same problem.
