Community
Participate
Working Groups
Build Identifier: M20100211-1343 Opening a file by double-clicking it does not give keyboard focus to the editor view, while all other methods of opening the file give the file keyboard focus. Reproducible: Always Steps to Reproduce: 1. In the Package Explorer, double-click on a java file to open it in the editor 2. Press CTRL + F to search for some text (or just type something) Expected results: The opened editor view has the focus, and CTRL + F opens the search dialog for the text editor. Actual results: Focus stay on the Package Explorer view, and CTRL + F opens the search dialog for the Package Explorer. This is an inconsistency with other ways of opening the file (F3, context menu > Open or Open with). I've tested that this happens consistently with .java, .txt and .php files.
Does the problem persist on Eclipse 3.6M7? http://download.eclipse.org/eclipse/downloads/ How did you download and install Eclipse? What distribution are you on? What versions of GTK+ do you have installed?
BuildId: M20100211-1343 Do you have any errors in your error log? <workspace>/.metadata/.log I tried this on the same build on linux. Double-click on a java file from the Package Explorer and once it is opened, hit CTRL+F. I'm now searching in the editor. PW
(In reply to comment #2) > Do you have any errors in your error log? <workspace>/.metadata/.log No.
(In reply to comment #1) > How did you download and install Eclipse? What distribution are you on? What > versions of GTK+ do you have installed? This is Eclipse 3.5.2 that comes with Ubuntu 10.04 (Lucid Lynx). I'm using libgtk 2.20.0.
I've just tested with a virgin workspace with a new project: The problem still occurs there as well. I'll test with Eclipse 3.6m7 now.
The problem persists with Eclipse 3.6M7. By the way, this is on KDE 4.4.2. I haven't tested this on Gnome yet.
Are you sure this is Package Explorer and not Project Explorer?
Yes, this occurs in the Package Explorer, but I can also reproduce the problem in the Project Explorer.
not sure where to send this, I'll assign to CommonNavigator but chances are that this is something buried lower since it seems to be a platform difference.
By the way, I've only seen this after the upgrade from Kubuntu 9.10 to Kubuntu 10.04 (which updated the OS and Eclipse). However, Zend Studio for Eclipse (a separate application) was also affected (and Zend Studio for Eclipse was the same version as before the upgrade). In case this might be relevant, this is how I start Eclipse and Zend Studio: /usr/bin/eclipse env GDK_NATIVE_WINDOWS=1 /home/klee/Zend/ZendStudio-7.1.1/ZendStudio Is there anything else which I'd need to check?
By the way, this problem does _not_ occur on the OS X version of Eclipse.
The problem persists in Eclipse 3.6. Details: Standard Eclipse Helios distro downloaded from eclipse.org; Ubuntu 10.04 64bit; Gtk+ 2.20.1-0ubuntu2.
I have the same problem. The only way to get editor focus is with the Project Explorer View detached Eclipse Java EE IDE for Web Developers. Version: Helios Release Build id: 20100617-1415 Fedora 13 x86_64 $ java -version java version "1.6.0_21" Java(TM) SE Runtime Environment (build 1.6.0_21-b06) Java HotSpot(TM) Server VM (build 17.0-b16, mixed mode)
I also have this issue. It's really annoying! :) uname info: Linux statum-laptop 2.6.32-24-generic #41-Ubuntu SMP Thu Aug 19 01:12:52 UTC 2010 i686 GNU/Linux Eclipse 3.5.2 Build id: 20100218-1602 Sun JDK 1.6.20 (32-bit) My command line: eclipse -vm /usr/lib/jvm/java-6-sun/bin/java -Xmx1024m -XX:MaxPermSize=256m Other folks have been reporting GTK version.. here is my dpkg output: ii libgtk2.0-0 2.20.1-0ubuntu2 Let me know if you need any info or want me to try something.
(In reply to comment #12) > The problem persists in Eclipse 3.6. > > Details: Standard Eclipse Helios distro downloaded from eclipse.org; Ubuntu > 10.04 64bit; Gtk+ 2.20.1-0ubuntu2. I am running the same Eclipse version OS and don't see the problem. I'm running Gnome, are you using KDE or Gnome?
(In reply to comment #14) > Other folks have been reporting GTK version.. here is my dpkg output: > ii libgtk2.0-0 2.20.1-0ubuntu2 This works fine on Ubuntu Jaunty (10.04) with: ii libgtk2.0-0 2.16.1-0ubuntu2
Everyone, please run this command to report the version of GTK you are using: dpkg -l | grep libgtk2.0-0
ii libgtk2.0-0 2.20.0-0ubuntu4 and it's still not working for me.
ii libgtk2.0-0 2.20.1-0ubuntu2 ... on Kubuntu 10.04, and not working
Installed Packages Name : gtk2 Arch : x86_64 Version : 2.20.1 Release : 1.fc13
Ok, seems like this is a GTK issue with GTK 2.20. Off to SWT.
(In reply to comment #15) > (In reply to comment #12) > > The problem persists in Eclipse 3.6. > > > > Details: Standard Eclipse Helios distro downloaded from eclipse.org; Ubuntu > > 10.04 64bit; Gtk+ 2.20.1-0ubuntu2. > I am running the same Eclipse version OS and don't see the problem. I'm running > Gnome, are you using KDE or Gnome? I am using Gnome. Here is the output you requested: [~]% dpkg -l | grep libgtk2.0-0 ii libgtk2.0-0 2.20.1-0ubuntu2
I'm experiencing the same issue.
Additional info: this problem does not occur when opening a file with the "Enter" key. It only seems to occur when double-clicking. Also, this problem is not limited to the opening of Java files. It seems to occur for any file type that opens an editor when double-clicked. Problem happens for me using build id M20100909-0800 on Ubuntu 10.10.
*** Bug 331081 has been marked as a duplicate of this bug. ***
Same problem. OpenSUSE 11.4, 64-bit. libgtk-2_0.0, v. 2.22.1-13.15.1. Eclipse Java EE IDE for Web Developers, Version: Indigo Release, Build id: 20110615-0604. NOTE: double-click works correctly (transfers focus to Editor window) for .xsd files(!). For all other files I have tried (.java, .xml, .xsl, pom.xml, etc.), double-click keeps focus in Package explorer, while Enter transfers focus to Editor window.
I can confirm bug for double click (unless view is detached). Enter works whether detached or not. ii libgtk2.0-0 2.20.1-0ubuntu2.1 Ubuntu 10.04 Eclipse 3.7.1 Build id: M20110909-1335
Created attachment 221871 [details] AutoFocusOpenedEditorPlugin.jar This "feature" was really driving me nuts, so I have written this simple plug-in which gives the stolen focus back to the opened / activated editor. Not the "real" solution, I guess, but at least it is working for me... :) The "autofocusopenededitorplugin/internal/conf.properties" file inside the jar gives the basic idea about the solution. I hope you can find it useful until this issue / root of the issue gets really fixed...
*** Bug 394462 has been marked as a duplicate of this bug. ***
From bug 394462 comment 1: => Analysis of the events: When I double-click a file in the Package Explorer, then Tree.gtk_row_activated(int, int, int) line: 2008 posts a DefaultSelection event. This is handled by org.eclipse.jface.util.OpenStrategy, which opens the editor and sets focus to the StyledText. But in the end, Control.gtk_button_press_event(int, int, boolean) line 2936 activates the Tree widget again: if (!shell.isDisposed ()) shell.setActiveControl (this); This line is wrong. If the control really needs to be activated again on double-click, then this needs to happen before any listeners are notified.
Here's a standalone snippet. If you double-click the tree item on Windows, the focus ends up in the Text as expected. On GTK, focus goes back to the Tree. (In reply to comment #30) The execution sequence in Control.gtk_button_press_event(int, int, boolean) is a bit convoluted: - First, the "sendMouseEvent (..., false, ...)" call *posts* a mouse down event, which is enqueued. - Then, the "shell.setActiveControl (...)" call *sends* an activate event, which is processed immediately. - Later, the enqueued mouse down is processed => The final order of the Activate, MouseDown, and DefaultSelection events is correct. The real problem is somewhere deeper in the SWT/GTK interaction. I first thought it's just the "OS.gtk_widget_grab_focus (handle);" at the end of Tree.gtk_button_press_event(int, int) on line 1891, but when I remove that and run the snippet, I still get some callbacks via windowProc that remove the focus from the Text again.
Created attachment 230644 [details] Snippet312568.java
The same issue still occurs on Ubuntu 13.04 using Default, Classic and GTK themes with eclipse kepler. Tested builds: * 4.3RC2a (Build id: I20130526-2000) * 4.3RC3 (Build id: I20130530-1430) Does not happen on Windows XP SP3.
Same issue with eclipse 4.3RC4 (Build id: I20130605-2000).
Same issue here. Archlinux using KDE 4.11.00 but not using archlinux's Eclipse. gtk2: 2.24.20-1 eclipse.buildId=4.3.0.I20130605-2000 java.runtime.name=Java(TM) SE Runtime Environment java.runtime.version=1.7.0_25-b15
Problem still in Luna RC1. PW
Kubuntu 14.04. Eclipse 4.4.0. So very disruptive to a workflow to open a file from the package explore and then try to find something in the file. It may not seem like much but when ctrl+f keeps searching the package explorer instead of the file, it is really, _really_ annoying. This is prompting me to try other IDEs because this is disruptive enough. I know that this used to work. It's unfortunate that it has become a persistent bug.
(In reply to JW from comment #37) I can only confirm, bugs like these don't make a good name to Eclipse. Have you tried the attached plugin as a workaround for this problem? (see comment #28)
Arun, can you please have this investigated? Thanks.
Working on this.
I have a ~Work-in-progress~ patch here: (NOT FULLY READY YET): https://git.eclipse.org/r/#/c/49702 There are 2 issues: 1) 11 year workaround that steals focus that is no longer relevant. (Removed it). see: git show 300ace8e3eaec6136b4861feec65efae8fe149fc 2) MouseDoubleClick event comes after DefaultSelection. Platform UI (quite logically) expects DefaultSelection to come after MouseDoubleClick. If I manually delay this event by 50ms then all works well. Now I'm looking for a better way to solve it than a 50ms delay. What I have in mind at the moment is : a. Not listen to ROW_ACTIVATION at all. Instead manually trigger defaultSelection after DoubleClick event occurred and get selection manually. b. Write some thread-wait mechanism that slows down DefaultSelection till after Double-click event went through. I'm researching which of those works best. Any thoughts/tips/advise is welcomed.
This also occurs on Gtk3 btw.
*** Bug 465984 has been marked as a duplicate of this bug. ***
(In reply to Leo Ufimtsev from comment #41) > I have a ~Work-in-progress~ patch here: > (NOT FULLY READY YET): > https://git.eclipse.org/r/#/c/49702 > > There are 2 issues: > > 1) 11 year workaround that steals focus that is no longer relevant. (Removed > it). > see: > git show 300ace8e3eaec6136b4861feec65efae8fe149fc Having this removed in separate commit is good idea as this is a must do stuff while the rest is not yet decided and we can push it as soon as devel opens. > > 2) MouseDoubleClick event comes after DefaultSelection. Platform UI (quite > logically) expects DefaultSelection to come after MouseDoubleClick. > If I manually delay this event by 50ms then all works well. > > Now I'm looking for a better way to solve it than a 50ms delay. > What I have in mind at the moment is : > a. Not listen to ROW_ACTIVATION at all. Instead manually trigger > defaultSelection after DoubleClick event occurred and get selection manually. > > b. Write some thread-wait mechanism that slows down DefaultSelection till > after Double-click event went through. > > I'm researching which of those works best. a) sounds better option to me > > Any thoughts/tips/advise is welcomed.
New Gerrit change created: https://git.eclipse.org/r/50031
(In reply to Alexander Kurtakov from comment #44) > (In reply to Leo Ufimtsev from comment #41) > > I have a ~Work-in-progress~ patch here: > > (NOT FULLY READY YET): > > https://git.eclipse.org/r/#/c/49702 > > > > There are 2 issues: > > > > 1) 11 year workaround that steals focus that is no longer relevant. (Removed > > it). > > see: > > git show 300ace8e3eaec6136b4861feec65efae8fe149fc > > Having this removed in separate commit is good idea as this is a must do > stuff while the rest is not yet decided and we can push it as soon as devel > opens. Submitted patch part 1: (removal of old workaround) https://git.eclipse.org/r/#/c/50031 Will work on part 2 now.
New Gerrit change created: https://git.eclipse.org/r/50125
Part 2 is finished: https://git.eclipse.org/r/#/c/50125/ Tree/Table/List now manually send the DefaultSelection after the double click event. I also added code so that it would send it - After a MouseDoubleClick event - Space (no modifiers) - Shift+space (and no other modifiers) - Return (no modifiers This is to preserve functionality of row-activation as per GtkDocu: https://developer.gnome.org/gtk3/stable/GtkTreeView.html#GtkTreeView-row-activated With these two patches double-clicking in package explorer now passes focus correctly to the editor. It also impacts all other tree-double click widgets, e.g double-clicking no a breakpoint now shifts focus to the code-line that the break-point is on. Etc.. Patches are ready for review.
Bug still exists on Mars.
(In reply to Marvin Fröhlich from comment #49) > Bug still exists on Mars. ~Patch not yet merged into master due to code freeze. Should make it into master in a week or two.
With patch 2 (the one that changes event order), can someone confirm that the event order is identical between Windows and GTK? It's probably best to keep the order consistent across platforms if possible, and probably best not to change the order if it's already consistent. I suspect the patch is probably good (and I've confirmed that the combination of both patches fixes the problem reported here) but I'd suggest we determine the event order across platforms before changing it on GTK.
Gerrit change https://git.eclipse.org/r/50031 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=a579313c784ea4e28a50457adea5fbc801f8c771
Gerrit change https://git.eclipse.org/r/50125 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=3db87a8763e3fd3f931295da165ddee8363a7b16
Both patches pushed to master. It's really good to see 5 years old bug finally going out. I don't have access to Windows box to test but this is really big usability issue so having it fixed sooner is more important in my eyes. If there is such an issue let's deal with it in separate bug.
Arun, what do you think about backporting the patches to Mars?
Created attachment 255028 [details] LTEST_312568_TreeDoubleClick.java Snippet to test patch and print order of events. - Order of events before patch :: mouse down mouse down Tree default selection. 319987237 Mouse double - Order of events after patch :: mouse down mouse down Mouse double Tree default selection. 320178740 Before patch: - Double clicking on Tree/Table/List had no impact on focus After patch : - Upon double clicking Tree/Table/List, focus shifts to text box.
(In reply to Leo Ufimtsev from comment #56) > - Order of events after patch :: > mouse down > mouse down > Mouse double > Tree default selection. 320178740 I can confirm that it is the same in Windows.
(In reply to Eclipse Genie from comment #53) > Gerrit change https://git.eclipse.org/r/50125 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=3db87a8763e3fd3f931295da165ddee8363a7b16 > The Widget#valueContainsFlag(..) doesn't meet SWT's coding style and quality standards: - The standard idiom in SWT is this: if ((keymask & (OS.GDK_MOD1_MASK | OS.GDK_SHIFT_MASK | OS.GDK_CONTROL_MASK | OS.GDK_SUPER_MASK | OS.GDK_META_MASK | OS.GDK_HYPER_MASK)) != 0) { sendTreeDefaultSelection(); } Also note the position of the '{'. The valueContainsFlag method should be removed again. If it would have been kept, the following would have had to be fixed: - Why is the type of 'value' long and not int? - Missing @return description. - Typo: Convienience (please check why you didn't see an error underline from the spell checker)
New Gerrit change created: https://git.eclipse.org/r/51524
(In reply to Markus Keller from comment #58) > (In reply to Eclipse Genie from comment #53) > > Gerrit change https://git.eclipse.org/r/50125 was merged to [master]. > > Commit: > > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=3db87a8763e3fd3f931295da165ddee8363a7b16 > > > > The Widget#valueContainsFlag(..) doesn't meet SWT's coding style and quality > standards: > > - The standard idiom in SWT is this: > > if ((keymask & (OS.GDK_MOD1_MASK | OS.GDK_SHIFT_MASK > | OS.GDK_CONTROL_MASK | OS.GDK_SUPER_MASK > | OS.GDK_META_MASK | OS.GDK_HYPER_MASK)) != 0) { > sendTreeDefaultSelection(); > } > > Also note the position of the '{'. Thank you for feedback. I've made the relevant refactoring and tested for functionality. (removed valueContainsFlag() method). I added you as reviewer: https://git.eclipse.org/r/#/c/51524/ Please let me know if there's anything else. > The valueContainsFlag method should be removed again. If it would have been > kept, the following would have had to be fixed: > > - Why is the type of 'value' long and not int? > - Missing @return description. > - Typo: Convienience (please check why you didn't see an error underline > from the spell checker) To this I shall link to this tweet: https://twitter.com/iamdevloper/status/614509767747178499 (On the side: I did have spell check turned on, but it seems by default Eclipse only picks up the first 100 spell check errors. The function being at the bottom of a 2000+ widget, Eclipse didn't get to the typo. I set my preferences to 9999 instead now)
Gerrit change https://git.eclipse.org/r/51524 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=e77894ec85aa5b0555b5293835b4f2449b791709
As I missed the issues in my review - I have reviewed and pushed it, all is good now.
(In reply to Alexander Kurtakov from comment #55) > Arun, what do you think about backporting the patches to Mars? Yes, please. This bug existed for a long time now. Would be a shame, if it was delayed till the next release.
Thanks for the cleanups and for not releasing my wrong proposal with "!= 0". I agree this should be backported, but only after a few weeks of testing in the 4.6 stream. Reopening for 4.5.1.
I don't know whether this is related, but on Gnome 3.16 with Mars there's a strange issue with list views: A click doesn't seem to reach the item, i.e. set focus on it. It only selects that view. This results in having to first focus the view and then click on an entry to get it selected. It also makes opening entries in the Navigator impossible via double click. Double-clicking on an Navigator item while having focus on an editor window opens the currently selected entry, no matter what item was actually double-clicked. Right clicks are also affected, e.g. showing properties for the currently selected file, not the one right clicked to get its menu. This confuses me a lot. Double-clicks on folders in the Navigator are not affected, single clicks (r and l) are. Folding / expanding arrows work as well.
(In reply to Alexander Hofbauer from comment #65) > I don't know whether this is related, but on Gnome 3.16 with Mars there's a > strange issue with list views: A click doesn't seem to reach the item, i.e. > set focus on it. It only selects that view. Hello, I tested latest Eclipse Mars with Gtk 3.16.5 (As well as with Gtk 2.24) with the double click patch. Works well for me, the issue described does not appear on my Fedora 22 system. (I'll attach video in a bit). May I suggest to submit a separate bug-report and post more details (e.g your OS, theme, perhaps a screen recording with gtk-recordMyDesktop to illustrate the issue?) and perhaps link to this bug as related. If you have the means, you could try to revert the SWT patch and see if the issue occurs for you without the patch; although this may require you to rebuild the SWT bindings.
Created attachment 255301 [details] Double click seems to work for me on Mars.
N
Oh, apparently a browser hiccup or something alike caused my comment to be truncated. Sorry for the noise. Thank you for your input. I added bug 473093, trying to describe my problem further.
As discussed in the other bug, bug 473093 is not related to this bug. As things stand, awating further feedback, otherwise we can probably backport it some time next week.
If there are no observed issues, we should consider backporting now to resolve this bug.
(In reply to Leo Ufimtsev from comment #71) > If there are no observed issues, we should consider backporting now to > resolve this bug. Arun, here is my +1 for backporting it.
(In reply to Alexander Kurtakov from comment #72) > (In reply to Leo Ufimtsev from comment #71) > > If there are no observed issues, we should consider backporting now to > > resolve this bug. > > Arun, here is my +1 for backporting it. +1 from me as well, Leo, please go ahead and release the patch to R4_5_maintenance. Thanks!
(In reply to comment #73) > (In reply to Alexander Kurtakov from comment #72) > > (In reply to Leo Ufimtsev from comment #71) > > > If there are no observed issues, we should consider backporting now to > > > resolve this bug. > > > > Arun, here is my +1 for backporting it. > > +1 from me as well, Leo, please go ahead and release the patch to > R4_5_maintenance. Thanks! Ok, I pushed it into R4_5_maintenance. Closing for now.
Verified on M20150826-1000 Linux x86 32bit
