Community
Participate
Working Groups
Show outline, Ctrl+O, followed by ESC to dismiss the window stop all other keybindings from working. This is easily reproduced but isn't 100%. The behaviour is similar to https://bugs.eclipse.org/bugs/show_bug.cgi?id=55581 in that 55581 would also stop keybindings from working until another view was focused and then the editor refocused. Verified using Build id: 200403251200
Additionally, not messages are written to the .log file
I cannot reproduce this bug on Windows XP or Linux-GTK. Could you be more specific?
That's unfortunate. This problem is making this build almost unusable. It is reproducible by opening the outline and pressing ESC. At that point most keybindings no longer work, especially keybinding that use the CTRL key. I'll try reproducing this with a clean workspace and post again. I'm running this on Gentoo linux with gtk+-2.2.4 glibc-2.3.2 sun jdk 1.4.2_04
Ok, I started with a new workspace and created a java project called Test with a single class file called Test in a package called test. I wasn't quite as easy to reproduce, but Ctrl+O then Esc definitely triggers the defect. Cycling editors also seems to trigger the defect. Ctrl+Shift+T then Esc causes it to happen. In fact Ctrl+Shift+T seems to cause it to happen everytime. If focus is in the editor window when the bug occurrs, then focusing the Outline view will restore keybinding operations. If focus is in the Outline view when the bug occurrs, then clicking in the Editor window restores keybinding operation. No messages are being traced to the .log file. Is there some other way for me to pin down what is happening (or not happening)? I'm happy to self-host and debug, but don't know where to start.
*** Bug 56261 has been marked as a duplicate of this bug. ***
Can you edit a text file, and insert a line: org.eclipse.ui/trace/contexts=true Then start Eclipse with "-debug /path/to/file". On the console, you should see information about what contexts are active at any moment. The question is: which contexts are active when you see your keys failing to work? Also, you can try: org.eclipse.ui/trace/handlers=true
Interesting. I added the -debug /opt/eclipse/tracer option and started it up. First thing I tried was Ctrl+Shift+T, Esc repeatedly. It wouldn't reproduce until I tried cycling editors using Ctrl+F6, then it reproduced easily. Here is the trace /opt/eclipse: CLASSPATH="" JAVA_HOME=/opt/sun-jdk-1.4.2.04 PATH=/opt/sun-jdk-1.4.2.04/bin:$PATH ./eclipse -debug /opt/eclipse/tracing -data /home/thume/work/workspace -vm /opt/sun-jdk-1.4.2.04/bin/java |tee /tmp/eclipse.log |tee /tmp/eclipse.log Install location: file:/opt/eclipse/ Configuration file: file:/opt/eclipse/configuration/config.ini loaded Configuration location: file:/opt/eclipse/configuration/ Framework located: file:/opt/eclipse/plugins/org.eclipse.osgi_3.0.0/ Framework classpath: file:/opt/eclipse/plugins/org.eclipse.osgi_3.0.0/core.jar file:/opt/eclipse/plugins/org.eclipse.osgi_3.0.0/console.jar file:/opt/eclipse/plugins/org.eclipse.osgi_3.0.0/osgi.jar file:/opt/eclipse/plugins/org.eclipse.osgi_3.0.0/resolver.jar file:/opt/eclipse/plugins/org.eclipse.osgi_3.0.0/defaultAdaptor.jar file:/opt/eclipse/plugins/org.eclipse.osgi_3.0.0/eclipseAdaptor.jar Splash location: /opt/eclipse/plugins/org.eclipse.platform_3.0.0/splash.bmp Debug-Options: /opt/eclipse/tracing Time loadBundles in the framework: 46 Time spent in registry parsing: null Time spent in package admin resolve: null Time spent resolving the dependency system: null Start VM: /opt/sun-jdk-1.4.2.04/bin/java -cp /opt/eclipse/./startup.jar org.eclipse.core.launcher.Main -os linux -ws gtk -arch x86 -showsplash /opt/eclipse/./eclipse -showsplash 600 -exitdata /opt/eclipse/./eclipse -exitdata 1f8010 -debug /opt/eclipse/tracing -data /home/thume/work/workspace -vm /opt/sun-jdk-1.4.2.04/bin/java -vmargs -cp /opt/eclipse/./startup.jar org.eclipse.core.launcher.Main
Just tried with build 200403251651. Seems I can use Ctrl+Shift+T and Ctrl+Shift+O repeatedly unless I try Next Editor (Ctrl+F6). After that, things get wonky.
I'm not able to reproduce this on winxp
There are no tracing options turned on in the console log you provided.
I thought that wasn't much information. Here's what the file looks like I used as a param to the -debug option: [fast] /opt/eclipse.broken: cat tracing org.eclipse.ui/trace/contexts=true org.eclipse.ui/trace/handlers=true
Did you mean the output would be printed to the console view? I don't have the console view visible. I just provided the standard output from the xterm I started eclipse from.
Quick thing I've noticed is that you are catting "/opt/eclipse.broken/tracing" while the debug option is "/opt/eclipse/tracing". But I may have forgotten an important line. Try adding: org.eclipse.ui/debug=true Naw, from the console is good. If you're on IRC, then join irc.freenode.net#eclipse and message "krzysiu".
Nevermind that eclipse.broken thing. It was all good when I actually ran the test. I'm at home now and will try and reproduce the problem on my gentoo laptop with additional debug line.
[slow] /opt/eclipse: CLASSPATH="" JAVA_HOME=/opt/sun-jdk-1.4.2.04 PATH=/opt/sun-jdk-1.4.2.04/bin:$PATH ./eclipse -debug /home/thume/eclipse.tracing -vm /opt/sun-jdk-1.4.2.04/bin/java -vmargs -Xmx190m |tee eclipse.log Install location: file:/opt/eclipse/ Configuration file: file:/opt/eclipse/configuration/config.ini loaded Configuration location: file:/opt/eclipse/configuration/ Framework located: file:/opt/eclipse/plugins/org.eclipse.osgi_3.0.0/ Framework classpath: file:/opt/eclipse/plugins/org.eclipse.osgi_3.0.0/core.jar file:/opt/eclipse/plugins/org.eclipse.osgi_3.0.0/console.jar file:/opt/eclipse/plugins/org.eclipse.osgi_3.0.0/osgi.jar file:/opt/eclipse/plugins/org.eclipse.osgi_3.0.0/resolver.jar file:/opt/eclipse/plugins/org.eclipse.osgi_3.0.0/defaultAdaptor.jar file:/opt/eclipse/plugins/org.eclipse.osgi_3.0.0/eclipseAdaptor.jar Splash location: /opt/eclipse/plugins/org.eclipse.platform_3.0.0/splash.bmp Debug-Options: /home/thume/eclipse.tracing Time loadBundles in the framework: 91 CONTEXTS >>> [org.eclipse.ui.contexts.dialogAndWindow, org.eclipse.ui.contexts.window] CONTEXTS >>> [org.eclipse.ui.contexts.dialogAndWindow, org.eclipse.ui.contexts.dialog] CONTEXTS >>> [org.eclipse.ui.contexts.dialogAndWindow, org.eclipse.ui.contexts.window] CONTEXTS >>> [org.eclipse.ui.contexts.dialogAndWindow, org.eclipse.ui.contexts.dialog] CONTEXTS >>> [org.eclipse.ui.contexts.dialogAndWindow, org.eclipse.ui.contexts.window] CONTEXTS >>> [] CONTEXTS >>> [org.eclipse.ui.contexts.dialogAndWindow, org.eclipse.ui.contexts.dialog] CONTEXTS >>> [org.eclipse.ui.contexts.dialogAndWindow, org.eclipse.ui.contexts.window] CONTEXTS >>> [org.eclipse.ui.contexts.dialogAndWindow, org.eclipse.jdt.ui.javaEditorScope, org.eclipse.ui.contexts.window] CONTEXTS >>> [org.eclipse.ui.contexts.dialogAndWindow, org.eclipse.ui.contexts.dialog] CONTEXTS >>> [org.eclipse.ui.contexts.dialogAndWindow, org.eclipse.jdt.ui.javaEditorScope, org.eclipse.ui.contexts.window] CONTEXTS >>> [org.eclipse.ui.contexts.dialogAndWindow, org.eclipse.ui.contexts.dialog] CONTEXTS >>> [org.eclipse.ui.contexts.dialogAndWindow, org.eclipse.jdt.ui.javaEditorScope, org.eclipse.ui.contexts.window] CONTEXTS >>> [] CONTEXTS >>> [org.eclipse.ui.contexts.dialogAndWindow, org.eclipse.ui.contexts.dialog] CONTEXTS >>> [org.eclipse.ui.contexts.dialogAndWindow, org.eclipse.jdt.ui.javaEditorScope, org.eclipse.ui.contexts.window] CONTEXTS >>> [org.eclipse.ui.contexts.dialogAndWindow, org.eclipse.ui.contexts.dialog] CONTEXTS >>> [org.eclipse.ui.contexts.dialogAndWindow, org.eclipse.jdt.ui.javaEditorScope, org.eclipse.ui.contexts.window] CONTEXTS >>> [org.eclipse.ui.contexts.dialogAndWindow, org.eclipse.ui.contexts.dialog] CONTEXTS >>> [org.eclipse.ui.contexts.dialogAndWindow, org.eclipse.jdt.ui.javaEditorScope, org.eclipse.ui.contexts.window]
Created attachment 8904 [details] tracing output This output is the full sequence from when the keybindings go goofy, I change the view, bring up a dialog, hit escape and they go goofy again.
Steps to reproduce: 1.) Focus to Java source editor 2.) Ctrl+F6 to switch to a Java class file 3.) Ctrl+F6 to switch back to the Java source editor 4.) Ctrl+Shift+T to open dialog 5.) Esc to close dialog The dialog context is still active. Clicking on another view changes the state to window.
This is a problem that appears to be specific to GNOME and most likely to the Metacity window manager itself. It seems that when a dialog is closed with "Esc" in Metacity, no activation or deactivation is sent for the shell. This is different than can be expected on KDE/kwin or on Windows XP. I suspect that this either a bug or a "feature" in Metacity itself, but I'm not sure. Steve: can you comment?
Created attachment 8910 [details] Patch to "org.eclipse.ui.workbench" This patches WorkbenchCommandSupport and WorkbenchContextSupport to include a traverse listener. The traverse listener waits until the event loop is idle (asyncExec), and then processes all submissions. It needs to wait, as the shell is not marked as active until later in the event processing loop. I've also added a small optimization: caching the reference to the display, so a method call isn't need every time it is required. Those listening to this bug: please test and provide feedback. I'm hoping to release this for the noon rebuild.
Seems better, but I can still repro the bug. Open a dialog and pressing Esc doesn't seem to trigger it anymore, but Next Editor does. 1. Open 2 editors 2. Ctrl+F6 twice to focus the same editor 3. keybindings no longer work This seems to be reproducible for me
I was just now able to repro this behaviour (non-patched) on a kde workstation. It is a lot harder though and not predictable.
We've put in a temporary workaround that seems to cover all cases, but we believe the bug is truly in SWT. Moving to SWT to fix post-M8. We will remove our workaround after M8 ships.
Which build will this workaround be included?
*** Bug 56362 has been marked as a duplicate of this bug. ***
The workaround is in the 1300 build today. As a warning, we don't guarantee the workaround will cover all cases. We do feel it makes the problem much harder to trigger.
The workaround seems to work pretty well. Thanks, M8 is a nice piece of work!
Doug, what exactly was the SWT bug again?
The problem is that the shell activation event is not reliable. You created a small test case I believe which demonstrated the problem. Using Metacity, shell deactivation/activation events are not sent when closing a dialog with a traversal key (e.g., "Esc", "Enter", etc.). This problem might occur on other window managers as well.
Right thanks. I'm going to change the title.
This seems to WORKFORME (after I fixed the bug where the dialog shell was not taking focus by adding a bogus button. The real bug has been fixed in HEAD but you don't have that yet). CAn ytou try it>? import org.eclipse.swt.*; import org.eclipse.swt.widgets.*; public class PR_56231 { public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setText ("Shell"); shell.setSize(200, 200); Button b1 = new Button (shell, SWT.PUSH); b1.setSize(32, 32); shell.open(); Shell dialog = new Shell(shell); dialog.setText ("Dialog - Press ESC"); Button b2 = new Button (dialog, SWT.PUSH); b2.setSize(32, 32); dialog.setSize(200, 200); dialog.open(); Listener listener = new Listener () { public void handleEvent (Event e) { System.out.println ("SWT.Activate " + e.widget); } }; shell.addListener (SWT.Activate, listener); dialog.addListener (SWT.Activate, listener); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
This bug report is old and things have changed in this area. I am having trouble reproducing these cases using metacity 2.4.55 (RHEL3), metacity 2.8.6 (FC3), kwin 0.95 (RHEL3) and kwin from KDE 3.3 (FC3). It may be worth revisiting this problem. I am going to close this bug as WORKSFORME, and Doug, maybe we should try removing the hacks to see what happens.
Workaround is backed out.
