Community
Participate
Working Groups
To reproduce, put this class in your workspace: public class Zip extends Foo { @Override void blam(String foo, int bar) { super.blam(); } void blam(int a, int b) { } void zo() { blam(); } } ...then open it in a java editor, move your cursor between the brackets of blam() and press ctrl-shift-space. A content assist window opens asking you which blam() you meant to use. Hover your cursor over the window trim. Observe that you get a mouseover affordance suggesting the window is resizable. Try to resize it. Observed: The window closes. Expected: The window resizes.
New Gerrit change created: https://git.eclipse.org/r/46971
ContentAssistant.java was closing the dialog in a number of situations. One of them seems to be focus change to another view. During the act of resizing, keyboard focus seems to be disabled in some circumstances (this bit I don't understand exactly) and SWT is firing a FocusEvent to the dialog. The dialog was handling treating this as a focus change and closing itself. However, the event was just informing the dialog that nothing had focus - not that focus had moved anywhere else yet. My fix was to add a check to ensure that something else actually has received focus before closing the dialog due to a focus event. I also added a check to ensure that the initial size of the dialog is large enough for the resize drag handles to be clickable and for some minimum content.
I won't make such a change during RC*. I'll take a closer look early 4.6.
New Gerrit change created: https://git.eclipse.org/r/47114
I can't reproduce this on Ubuntu 15.04 with GTK 2.24.27 (SWT_GTK3=0) and GTK 3.14.12. Can you add information about your distribution and GTK version? Thanks!
Ubuntu 14.0.4 LTS My gtk versions: 2.24.23-0ubuntu1.2 3.10.8-0ubuntu1.4
Re: comment 4 I can't actually reproduce it right now, either. However, since one of the characteristics of this bug is a null focus control, I suspect that the SWT bits may be related to bug 469525. That bug is intermittent since it depends on the SWT event order, so it's possible that this one is intermittent, too.
(In reply to Stefan Xenos from comment #7) > Re: comment 4 > > I can't actually reproduce it right now, either. > > However, since one of the characteristics of this bug is a null focus > control, I suspect that the SWT bits may be related to bug 469525. That bug > is intermittent since it depends on the SWT event order, so it's possible > that this one is intermittent, too. OK, let's close this bug and reopen it if someone sees this again.
I can confirm this bug. My system is Ubuntu 15.04 with - libgtk version 3.14.13-0ubuntu1 - libgtk2 version 2.24.27-0ubuntu1 and Eclipse Mars on OpenJDK 1.8.0_45 (also Ubuntu-Version) Fist of all we have to distinguish between the two versions of "Content Assist": 1) The first version is accessible via CTRL-SPACE and is identifiable by the status bar showing "Press 'Ctrl+Space' to show ..." 2) The second version is accessible via CTRL-SHIFT-SPACE and does not contain the status bar The first version works perfectly as expected. It keeps the size every time you invoke it and is resizeable with the mouse. The second version does show the misbehavior. It is not resizeable, as it disappears on resizing with the mouse. Also it shrinks every time you invoke the content assist (by a small amount), until it is totally useless as it is almost invisible. It helps to edit workspace/.metadata/.plugins/org.eclipse.jdt.ui/dialog_settings.xml and increasing the value <section name="completion_proposal_size"> <item value="357" key="contextSelector.size.y"/> <item value="889" key="contextSelector.size.x"/> </section> If you make it large you can invoke the content assist several times before it shrinks to almost zero. What scares me is, that this bug is related to Bug 23980 which is almost thirteen years old. It would be great if one could make the second version like the first (working) one.
Reopening, as per Marcel's comment.
I can also confirm the bug on openSUSE 13.2 with Eclipse Mars. And just to make sure that this is not a new bug, I can also confirm this on Knoppix 7.4.2, Eclipse 3.8.1 with libgtk3 (3.12.2) and libgtk2 (2.24.24) On the other hand a MacOSX 10.10.4 (with Mars) is not affected; Windows 8.1 64bit (with Mars) does also work as expected.
Fixing the summary: This is about Parameter Hints (Ctrl+Shift+Space) on GTK. There are some platform inconsistencies in SWT APIs about focus and activation events that have never been fixed or documented completely. The workaround that has been in use for ages is to use Display#getActiveShell() instead of trying to call #isFocusControl() on all possible controls. See e.g. bug 62652, bug 23980, the Javadoc of IInformationControlExtension5, and http://git.eclipse.org/c/platform/eclipse.platform.text.git/diff/org.eclipse.jface.text/src/org/eclipse/jface/text/contentassist/CompletionProposalPopup.java?id=cef6230e04a6f55f8bb087bfd0ca0d40e1fdfacd The fix is to use the same code in ContextInformationPopup (which is in large parts an outdated copy of CompletionProposalPopup).
New Gerrit change created: https://git.eclipse.org/r/72056
(In reply to Markus Keller from comment #12) > The fix is to use the same code in ContextInformationPopup (which is in > large parts an outdated copy of CompletionProposalPopup). I've pushed that fix on behalf of you with http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=a42daa50b482b9f5f93b024be42757c427433f1e
Verified in I20160512-1000.
