Bugzilla – Full Text Bug Listing
| Summary: | Eclipse editor losing keyboard shortcuts focus after autocompletion | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | ppdkseth222 | ||||
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> | ||||
| Status: | RESOLVED WORKSFORME | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | eclipse.felipe, ericwill, gheorghe, pwebster, remy.suen | ||||
| Version: | 3.5 | Keywords: | triaged | ||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux-GTK | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
ppdkseth222
(In reply to comment #0) > 5. The keyboard shortcut focus can be fixed by clicking the window manager's > titlebar which however doesn't look like it had lost focus earlier on. This > operation also fixes the color of the eclipse editor's tab so it looks like a > focused editor. This sounds like a shell and widget activation event problem > > I am using Debian Linux squeeze/sid, Which version of GTK+ is installed in this distro? There are some well known problems with 2.18.x interactions with eclipse. PW I forgot to mention that i have a "fix" already applied for another UI problem i had with the buttons. Many buttons wouldn't react to mouse interaction and after a search i did on the web i found that i needed this environmental variable exported prior to Eclipse running: GDK_NATIVE_WINDOWS=1. However the issue with keyboard shortcut focus existed prior to this. The GTK version is 2.18.6-1. I just checked libgtk's website and it seems that 2.18.x is really their stable release, and it sounds very tricky to me to change to a different version, cause 2.19 would be their development/experimental and 2.16 is old which means it would only be the default version on some old distribution. Yes, on my previous Linux installation - Mandrake 9.2 - i didn't had that problem, but that distro came out at 2003. GDK_NATIVE_WINDOWS=1 is the only fix I know. Passing to SWT for comment. The Platform is listening on SWT.KeyDown events, but it sounds like the window isn't getting focus after the code completion. PW I reproduced the bug on Ubuntu Linux 9.10 (Karmic Koala), which is using GTK 2.18.3-1, and its included Eclipse package (Version: 3.5.1 Build id: M20090917-0800). I also reproduced the bug on the above Linux installation and Eclipse 3.5.2 Build id: M20100211-1343, for both GDK_NATIVE_WINDOWS=true and GDK_NATIVE_WINDOWS=false Finally, i reproduced the bug on the above Linux installation and Eclipse 3.6M6 (Version: 3.6.0 Build id: I20100312-1448), for both GDK_NATIVE_WINDOWS=true and GDK_NATIVE_WINDOWS=false I noticed that i get similar behavior on another case - when i focus on a popup (other than the code completion one) by clicking in its area or by pressing the F2 key and then exit it by pressing ESC. However if after focusing it but before pressing ESC i traverse the popup's window border once with the mouse, without clicking anywhere, and then press ESC the bug won't happen. With the above knowledge i returned to my original case and found out this: If i press ctrl+space, move the mouse inside the code completion area, click *once* (which makes the popup take focus and the editor losing it), then traverse the popup's window border, then re-enter it and double click some completion entry, the bug won't happen. I had a look at the source code and from my very little understanding of how all this works, i think the issue is somewhere here: class: org.eclipse.swt.widgets.Shell method: void bringToTop (boolean force) This method uses an X11 call when the widget has style SWT.ON_TOP, but when it doesn't have that style it uses a GTK call. Now this issue appears between the Editor which as far as i have found doesn't use the SWT.ON_TOP style and popup windows which use that style. My guess is that we ask first the X11 to focus the popup without telling anything to the GTK, and a bit later when we dispose that popup we ask the GTK to focus on the Editor, which though is the widget that GTK thinks the focus is applied already so maybe they implemented some kind of optimization on 2.18 GTK in order to ignore this kind of call. I have no idea how to fix this properly cause there are more bugfixes in this piece of code. Created attachment 180752 [details]
Proposed workaround
This is my proposed workaround around this issue.
I 'll try increasing the priority in order to get a review from the maintainers.
Hey Bog, can you check this problem for us ? I cannot reproduce this issue, please file a new ticket against 4.8 if the issue reoccurs on GTK3.22. |