Community
Participate
Working Groups
3.0RC3 Not sure if this is related to bug 58642, bug 65985 or bug 65053, but they are all fixed for RC3. Example copied from bug 57311 comment 12: - Have this class: class C { void m() { System.out.println(); } } - caret on println - press F2 -> popup - press Esc -> popup goes away -> editor quickly gains focus, but then looses it again -> no keyboard focus, only the main menu works I only marked this as critical because it seems to be an unfixed case of the bugs noted above. On its own, this is major.
I have tried to reproduce this problem but cannot. Could you please double-check that this is happening in I200406192000? You are using GTK+ 2.2.1, right?
I keep forgetting... $ rpm -q gtk+ gtk2 kdebase gtk+-1.2.10-25 gtk2-2.2.1-4 kdebase-3.1-15 Yes, this is on I200406192000.
Note that, other than bug 65053, left-clicking into the editor fixes the problem. It really just looks like the focus is somwhere else (but Ctrl+Tab won't help).
I can't reproduce it here on Gtk+ 2.2.1, 3.0-RC3. For kicks, can you post a screenshot of your setup? Also, where is your mouse located when this happens?
Created attachment 12570 [details] before_popup.png Shows screenshot with everything ok: caret in 'println'. The mouse cursor is somewhere where where it will not interfere with the popup shown in the next attachment, for example in the whitespace to the right of the package statement. To get the popup from this setup, press F2.
Created attachment 12572 [details] with_popup.png Popup showing. The javadoc popup has the focus, you can scroll around etc, which is fine (make sure you get the popup by pressing F2, not the mouse hover). Note that the editor is grey, i.e. does not have the focus. When pressing Esc in this situation, the popup will go away, but editor focus is not restored. The focus is gone. - Global menu bar works - System key bindings (Alt+Tab etc.) work. Using Alt+Tab to switch applications and back to eclipse brings back the focus.
OK, I can reproduce this easily now under kwin 0.95 / KDE 3.1-13 Red Hat.
When it occurs, Display.getActiveShell() and Display.getFocusControl() are both null. This may again be related to bug 65985. To reproduce, you need to use KDE 3.1 and GTK+ 2.2, since Doug cannot reproduce under KDE 3.2 and GTK+ 2.4.
I just checked: we don't regularly dispose of the popup shell when it hides - the shell is kept invisible and reused by the next popup. It is disposed when the subject (=editor) is. Pressing Esc however seems to dispose of the shell, since the internally used StyledText translates the Esc key somehow (not sure about this one).
> Pressing Esc however seems to dispose of the shell, since the internally used > StyledText translates the Esc key somehow (not sure about this one). This is wrong. DefaultInformationControl registers a keylistener with the StyledText and disposes upon Esc (hardcoded).
Here is a log of what happens to shell.hasFocus when I hit ESC: [key] activeShell = Shell {Java - C.java - Eclipse Platform}, focusControl = StyledText {} Shell.bringToTop() setting hasFocus = false Shell.bringToTop() setting hasFocus = true Shell.gtk_focus_out_event() setting hasFocus = false Shell.gtk_focus_in_event() setting hasFocus = true Shell.bringToTop() setting hasFocus = false Shell.bringToTop() setting hasFocus = true Shell.gtk_focus_in_event() setting hasFocus = true Shell.gtk_focus_out_event() setting hasFocus = false And now we are hosed. Switching between windows corrects the problem.
Here comes my debug trace: # pressing F2: KEYS >>> Listener.handleEvent(type = KeyDown, stateMask = 0x0, keyCode = 0x100000b, character = 0x0) KEYS >>> WorkbenchKeyboard.press(potentialKeyStrokes = [F2, NUL]) KEYS >>> WorkbenchKeyboard.executeCommand(commandId = 'org.eclipse.jdt.ui.edit.text.java.show.javadoc') KEYS >>> value for 'id' attribute = null KEYS >>> value for 'enabled' attribute = true KEYS >>> executing 'org.eclipse.ui.commands.ActionHandler' (492445018) CONTEXTS >>> [org.eclipse.ui.contexts.dialogAndWindow, org.eclipse.ui.contexts.dialog, org.eclipse.jdt.ui.javaEditorScope] # in the popup, pressing Esc: KEYS >>> Listener.handleEvent(type = Traverse, stateMask = 0x0, keyCode = 0x1b, character = 0x1b) KEYS >>> Listener.handleEvent(type = Traverse, stateMask = 0x0, keyCode = 0x1b, character = 0x1b) CONTEXTS >>> [org.eclipse.ui.contexts.dialogAndWindow, org.eclipse.jdt.ui.javaEditorScope, org.eclipse.ui.contexts.window] # from now on: no trace whatsoever
Here is what we think is going wrong. Shell.fixShellFocus() is trying to work around a GTK+ bug by sending a fake FocusOut event to try and clear some GTK+ state. However, if the control that receives the FocusOut event does not have focus already, GDK will send a FocusOut event up to the application. This event then clears the hasFocus flag on Shell and causes the behaviour you see.
This is something we should investigate/fix for 3.0, as it really causes disruption in workflow.
We released a fix for this. Fixed > 20040623. This is really a bug in GTK and if this fix is not enough, we are going to remove the whole Shell.fixShellFocus() code.
I can still reproduce this in I200406240800 but not in HEAD. I assume it didn't yet make it into the builds.
This fix is broken in at least 3 ways: 1.) It has the potential to create a race condition with focus follows mouse. Moving the mouse around the screen, it is possible for Eclipse to steal focus after the mouse has left the window. 2.) "Alt+Tab" to another window in KDE. A pop-up appears while switching -- telling you which window you will switch to. Releasing "Alt" while another window is selected, brings that window to top. However, Eclipse will not repaint the section dirtied by the pop-up. 3.) Taking a screenshot and switching desktops caused the following. This is likely because of a race condition in which the input focus is being set on a window that is no longer mapped. The program '<unknown>' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 183493 error_code 8 request_code 42 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.)
Fixed again (SSQ). Billy and Doug, can you guys verify the new fix in HEAD ? Thanks
After using Eclipse from HEAD for a while under KDE 3.1 on RH9, I was able to reproduce the caret-disappears problem from bug 58642.
I have reproducable steps for a persistent editor drop-down using the code from HEAD. KDE 3.1, RH9, Mist theme, Gtk+ 2.2.1. 1. Enter the Debug perspective. 2. Click on the contents of the variables view. 2. Click the editor drop-down. 3. Click back on the variables view, this closes the drop-down. 4. Click the editor drop-down again. It is now persistent and won't go away.
Sorry, those steps are unreliable. These steps are awesome. 1. Debug perspective. 2. Click on the outline view's tree view. 3. Click on the editor drop down. 4. Click on the variables view. You're now in the bad state. I will attach a screenshot of my setup.
Created attachment 12804 [details] My setup
(Doug speaking:) From this bad state, just by fiddling around I was able to descend into a place from which there is no return. Eclipse will not shutdown properly (needs to be hard killed), the editor drop-down is open and can't be closed, and there is no focus control.
