Community
Participate
Working Groups
Created attachment 280569 [details] Video that shows the problem. Steps to reproduce: 1. Invoke content assist in a Java editor. 2.a) Either enlarge the pop-up a lot (by resizing it). 2.b) Or enlarge the pop-up (by resizing it) and scroll down in the pop-up. 3. Observe that the contents of the pop-up are gone. See the attached video "content_assist_gone_on_resize.mp4". The same is seen for the debug hover, while debugging a Java application. We observe this in 4.12 but its also reproducible with 4.14 M1. We observe it on RHEL 7.4 with GTK 3.22.10. I don't see this with Eclipse 4.13 and Windows 10, so I assume its Linux/GTK3 related.
(In reply to Simeon Andreev from comment #0) > I don't see this with Eclipse 4.13 and Windows 10, so I assume its > Linux/GTK3 related. Moving to SWT.
(In reply to Simeon Andreev from comment #0) > Created attachment 280569 [details] > Video that shows the problem. > > Steps to reproduce: > > 1. Invoke content assist in a Java editor. > 2.a) Either enlarge the pop-up a lot (by resizing it). > 2.b) Or enlarge the pop-up (by resizing it) and scroll down in the pop-up. > 3. Observe that the contents of the pop-up are gone. > > See the attached video "content_assist_gone_on_resize.mp4". > > The same is seen for the debug hover, while debugging a Java application. > > We observe this in 4.12 but its also reproducible with 4.14 M1. We observe > it on RHEL 7.4 with GTK 3.22.10. > > I don't see this with Eclipse 4.13 and Windows 10, so I assume its > Linux/GTK3 related. Can you please provide the following information 1. X11 or Wayland 2. scaling factor used 3. I am assuming Gnome desktop. if not please let us know
1. X11. 2. I don't think I've touched such settings, so it must be the default. How do I check? 3. We have KDE. Not seen with: Eclipse SDK Version: 2019-03 (4.11) Build id: I20190307-0500 First version I have that I see it in is: Eclipse SDK Version: 2019-06 (4.12) Build id: I20190402-1800 I'm looking for the commit that caused the regression right now, will let you know when I find it.
This "fixes" it: diff --git a/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Table.java b/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Table.java index 67ebd442fe..31a20d98f7 100644 --- a/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Table.java +++ b/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Table.java @@ -297,7 +297,7 @@ boolean checkData (TableItem item) { * the wrong cells to be rendered. */ if (!GTK.GTK4 && GTK.GTK_VERSION >= OS.VERSION(3, 18, 0)) { - GTK.gtk_style_context_invalidate(GTK.gtk_widget_get_style_context(handle)); + //GTK.gtk_style_context_invalidate(GTK.gtk_widget_get_style_context(handle)); } return true; } diff --git a/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Tree.java b/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Tree.java index a404b04c21..15e14c6362 100644 --- a/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Tree.java +++ b/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Tree.java @@ -347,7 +347,7 @@ boolean checkData (TreeItem item) { * the wrong cells to be rendered. */ if (!GTK.GTK4 && GTK.GTK_VERSION >= OS.VERSION(3, 18, 0)) { - GTK.gtk_style_context_invalidate(GTK.gtk_widget_get_style_context(handle)); + //GTK.gtk_style_context_invalidate(GTK.gtk_widget_get_style_context(handle)); } return true; } So the regression is from bug 531048, commit: https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=092d68d1c71497fe32622e65742008ee50a1bac2
Happens on GNOME and with Adwaita as well?
(In reply to Eric Williams from comment #5) > Happens on GNOME and with Adwaita as well? On Adwaita, yes. No idea about GNOME though, we have only KDE I think.
(In reply to Simeon Andreev from comment #6) > (In reply to Eric Williams from comment #5) > > Happens on GNOME and with Adwaita as well? > > On Adwaita, yes. No idea about GNOME though, we have only KDE I think. Okay, I can reproduce it as well, will investigate.
Interestingly enough the regression only happens on 3.20+ with the fix from bug 531048 applied. GTK3.18 works fine. I'll bisect GTK to see what's going on there as it might shed some light on the issue. Bug 531048 seems to have introduced the bug where the content assist's content isn't shown, but what's odd is that if I revert bug 531048 the issue with the scroll bar is still there. For example if you resize the popup and scroll, the scroll bar doesn't move and seems generally broken. I'm starting to wonder if some existing issue exists here and the fix for bug 531048 just made it worse. I'll keep looking for a fix. If nothing comes of this by M3 I'll revert bug 531048.
(In reply to Eric Williams from comment #8) > I'll keep looking for a fix. If nothing comes of this by M3 I'll revert bug > 531048. Thanks, this issue was just reported by another user of a different part of our software. Seem that some people like to resize popups :-)
New Gerrit change created: https://git.eclipse.org/r/152614
Gerrit change https://git.eclipse.org/r/152614 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=0a21e355dfce03c777b4d032249b0ce9f825dd86
(In reply to Eclipse Genie from comment #11) > Gerrit change https://git.eclipse.org/r/152614 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=0a21e355dfce03c777b4d032249b0ce9f825dd86 Reverted the change.
Thanks Eric! Verified with build I20191113-2315.
