Community
Participate
Working Groups
Steps to reproduce: 1. open a java source file in eclipse 2. move the cursor to a method call 3. press F2 to see quick docs 4. press Esc to make the quick docs window and the cursor from the java editor to disappear Effect: the cursor can nowhere be seen in the java editor but can be moved, type at, etc. If I switch virtual workspaces back and forth, the cursor comes back. Environment: linux gtk2, gnome2.6 with openbox3 and metacity window manager Comment: it happens every time with openbox3. It tend to happen only for the second try using metacity.
Correction: Environment: linux gtk2, gnome2.6 with openbox3 and metacity window manager, Eclipse 3.0M8
Also seen on I20040413.
I have seen this as well but have not been able to reproduce consistently so far, neither with the steps you describe.
Try pressing F2 and then ESC almost immediately. If you wait for too long, the bug does not seem to occur.
ok, was able to reproduce. I'll try to see if this is due to the editor caret handling or some platform / swt problem.
still exists in M9, same steps can be used to reproduce. do we have any progress on this issue?
should be looked at for 3.0
Still reproducable, although one has to try many times. We don't do anything with the caret in the editor land. I suspect that StyledText somehow loses the caret. After I restore the caret (by switching to another editor and back), I can no longer reproduce. Moving to swt as I don't see where the editor / viewer could play a role here.
moving to SWT - feel free to move back if you think it's not the widget.
FH I can reproduce this with gtk 2.4.0 only.
I can reproduce it just as easily with Gtk+ 2.2.1 as with Gtk+ 2.4.
Created attachment 11300 [details] C code with the same problem Note that when the main shell loses focus to the tmpShell it does not receive focus-out event. If the type of tmpShell is changed to GTK_WINDOW_TOPLEVEL the problem doesn't happen. the compile and run this example: gcc -o t `pkg-config --cflags --libs gtk+-2.0` pr58642.c ; ./t
Billy, note that GTK does not give focus for ON_TOP shell, but SWT does during the Shell#bringToTop() using X Calls: ... int /*long*/ window = OS.GTK_WIDGET_WINDOW (shellHandle); if ((style & SWT.ON_TOP) != 0 && OS.GDK_WINDOWING_X11 ()) { int /*long*/ xDisplay = OS.gdk_x11_drawable_get_xdisplay (window); int /*long*/ xid = OS.gdk_x11_drawable_get_xid (window); OS.gdk_error_trap_push (); OS.XSetInputFocus (xDisplay, xid, OS.RevertToParent, OS.gtk_get_current_event_time ()); OS.gdk_error_trap_pop (); } else { ...
Felipe: Silenio pointed me at that code earlier today. I looked into why GDK wasn't giving focus, and ended up filing this bug: http://bugzilla.gnome.org/show_bug.cgi?id=143349 However, I do not think the problem I was tracing regarding dispose events being lost after the ON_TOP window is disposed is related to this GDK bug. It may be important to yours, though. (The X code that SWT does is functionally equivalent to what the fixed GDK code would do, BTW)
Felipe, it seems that if I add to your C example the code to set the X input focus that SWT does then I cannot reproduce the problem.
Created attachment 11337 [details] C app that shows a possible solution I have some useful information about the behaviour of Gtk+. In summary, using XSetInputFocus is bad and confuses Gtk+ into thinking there is no window manager present. However, without it one must grab the pointer and keyboard before being able to give focus to an override_redirect shell. Use: 1. The program is a main window with an entry in it. 2. Press a key, an override redirect window appears, also containing an entry. 3. Press a key again, we attempt to give focus to the window. 4. Press a key again, the window is destroyed. This program's behaviour is controlled by two constants at the top: const int USE_GRAB = 0 : Do not grab the pointer and mouse const int USE_GRAB = 1 : Grab the pointer and mouse const int USE_XSETINPUTFOCUS = 0 : Use gtk_widget_grab_focus const int USE_XSETINPUTFOCUS = 1 : Use XSetInputFocus Cases: USE_GRAB = 0, USE_XSETINPUTFOCUS = 1 - I think this is a close approximation of Eclipse. The window appears and is given focus fine, however when it disappears, try moving your mouse in and out of the window. Gtk+ has entered its own 'focus-follows-mouse' mode, compensating for what it believes is a lack of a Window Manager. I believe this causes all kinds of weirdness. USE_GRAB = 0, USE_XSETINPUTFOCUS = 0 - This shows why we use XSetInputFocus in the first place. The override_redirect window can never get focus !!!! USE_GRAB = 1, USE_XSETINPUTFOCUS = 0 - This works as we want. All of the events make sense, and we can give the focus using gtk_widget_grab_focus like normal.
I will try your ideas on Eclipse and see how it goes, I'll report back the results.
SSQ, FH, SN and BB to work on this for RC2.
*** Bug 65135 has been marked as a duplicate of this bug. ***
Created attachment 11916 [details] Test3 Billy, check this out. It proves the our approach can work! In C is easy to see what is happening and make the code works, in Java all that framework makes everything obscure and hard to understand. But now that we know that is can work we should give another try tomorrow.
Your C code works great for me too. It's a bit annoying that it is so close to what we thought we were doing in the Java code :)
Billy, I got it to work on Java/SWT, but still having some problems in the interactions ON_TOP Shell <-> Others apps.
Fixed > 20040617.
I saw this again in I200406171625.
My reproducible steps in I200406171625 are the following: 1.) Open a compare editor from a fast view. (I have tried this in two ways. The first way is to open the CVS resource history view as a fast view, select two versions of the open file, and select compare. The second way is to open the synchronize view as a fast view, select one of the changes and double-click on it.) 2.) In the compare editor, click inside one of the boxes marking a change. At this point, the selection in the file goes away as does the caret. The title bar changes colour to a faded version of the selected gradient. This is not exactly the same as the "on top but not active" colour, as that colour does not appear as a gradient on this machine. The workbench window is painted by the window manager as having focus, but: + No view/editor title bars are painted as if they have focus. + Clicking in different views passes this faded focus colour around. + The caret does not appear + No keys work -- not key bindings, typing or "ctrl+clicking" Activating a new shell (either within Eclipse, or a different application) fixes this problem. GTK+ 2.4.1, KDE 3.2.2, Linux 2.6.4.
Billy and I are working on this problem. Feel free to stop by. We have found the following: 1.) This test case is reproducible on Billy's machine as well as mine. 2.) There is an unmatched focus out event, which clears the active shell. No active shell means no focus control. 3.) Commenting out the XSendEvent in Shell.fixShellFocus() does not seem to correct this problem.
Rolling back Display, Control and Shell to v3058b corrects the regression I'm seeing. We'll now try to track down the exact commit that caused the problem.
It was Steve's commit for Bug 65985 that caused this problem. I will re-open this bug, and move this bug back to fixed.
*** Bug 50638 has been marked as a duplicate of this bug. ***
*** Bug 53504 has been marked as a duplicate of this bug. ***
*** Bug 53296 has been marked as a duplicate of this bug. ***
*** Bug 56661 has been marked as a duplicate of this bug. ***
This feels like necro-postings since this bug was closed 13 years ago, but I am still experiencing this issue today in Eclipse Oxygen. It happens occasionally, just like 65135. The steps to reproduce mentioned here, pressing F2 and quickly after pressing escape reproduce it reliably for me. This is on Ubuntu 16.04.03 using i3wm as window manager and java 1.8. Since i3 is not a mainstream window manager, maybe it's something to do with GTK thinking there is none?
Hi, I am getting this error with Eclipse 2019-12 running under the i3 window manager. Since tiling window managers are relatively popular these days, it would be lovely to have a resolution to this as it makes editing substantially more difficult. According to the discussion sixteen (!) years ago, Steve Northover's fix for bug 65985 led to this bug. In the discussion on that bug, Steve reported the bug "Fixed > 20040615" which I take to probably mean that his fix was committed in SVN(?) revision 20040615. Or perhaps that's 15 Jun 2004, I guess that makes sense, too. I don't know my way around Eclipse's source repositories well enough to track down the specific offending commit, or to trace it forward to the current codebase, but in my mind that would be the next course of action. If assistance is needed in reproducing this bug in the present day, I am at your service. I'll add that this bug may also be connected with a related problem which also occurs in 2019-12 (as well as the prior version) in which the autocomplete popup will not respond to input. At least, the two errors both arose for me at the same time. Thanks
