Bug 549186 - [GTK] Help box when hovering on Java constant does not completely disappear
Summary: [GTK] Help box when hovering on Java constant does not completely disappear
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 4.13   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-SWT-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2019-07-11 12:28 EDT by John Ganci CLA
Modified: 2020-03-22 00:10 EDT (History)
2 users (show)

See Also:


Attachments
Screenshot showing help box when hovering over Java constant (1.21 MB, image/png)
2019-07-11 12:28 EDT, John Ganci CLA
no flags Details
Terminal output running eclipse on fedora 27 with SWT_WEBKIT2=1 and on fedora 30 with SWT_LIB_VERSIONS=1 (3.33 KB, text/plain)
2019-07-11 14:56 EDT, John Ganci CLA
no flags Details
Picture of screen after move mouse off of help box (2.01 MB, image/jpeg)
2019-08-14 12:58 EDT, John Ganci CLA
no flags Details
Terminal output running eclipse on fedora 27 with SWT_WEBKIT2=0 (1.59 KB, text/plain)
2019-10-29 22:42 EDT, John Ganci CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description John Ganci CLA 2019-07-11 12:28:29 EDT
Created attachment 279250 [details]
Screenshot showing help box when hovering over Java constant

Running fedora 30, Oracle JDK 1.8.201, Eclipse 2019-06.

When hovering over a Java constant in the ecllipse text editor area, a help box appears, as expected. See attached screenshot for an example and for what follows. Note that the help box extends beyond the eclipse window. When the mouse is moved away from KEY_ANTIALIASING, the portion of the help box within the eclipse window, plus about 1/8 inch to the right, disappears, as one expects. However, the remainder of the help box remains on the screen. Tried to take a screenshot of this, but the area disappears when the screenshot is taken. The following shows a text version of what I see:
    +-------------------------------
    |
    |geometry rendering methods
    | dges of shapes.
    |
    | pixel along the boundary of
    |l coverage of the shape.
    |
    +-------------------------------
Hopefully you can see what I mean by looking at the attached screenshot. Additionally, sometimes the "artifact" rapidly flickers. One way to remove the artifact is to move the mouse to the top of the screen.

Repeating the test on fedora 27, Oracle JDK 1.8.201, Eclipse Photon (2018-06) behaves as expected: same help box appears when hovering on KEY_ANTIALIASING and completely disappears when moving the mouse off of KEY_ANTIALIASING. So, the problem is either with eclipse 2019-06 (doubtful) or fedora 30 (probably the gtk3 in fedora 30). See bug 548629 where I first asked about this issue.
Comment 1 Eric Williams CLA 2019-07-11 13:24:49 EDT
Can someone try to reproduce on Windows or Mac? If not it could be an SWT issue.
Comment 2 Paul Pazderski CLA 2019-07-11 13:32:49 EDT
(In reply to Eric Williams from comment #1)
> Can someone try to reproduce on Windows

No problem on Windows.
Comment 3 Paul Pazderski CLA 2019-07-11 13:33:08 EDT
PS: Windows 10
Comment 4 Eric Williams CLA 2019-07-11 13:49:32 EDT
John, can you try running Eclipse on Fedora 27 with SWT_WEBKIT2=1? I.e.:

export SWT_WEBKIT2=1
./eclipse

and see if the bug reproduces? Also, can you run (on any Fedora) with SWT_LIB_VERSIONS=1 and share the output that is printed when running Eclipse with that? Thanks.
Comment 5 John Ganci CLA 2019-07-11 14:56:33 EDT
Created attachment 279252 [details]
Terminal output running eclipse on fedora 27 with SWT_WEBKIT2=1 and on fedora 30 with SWT_LIB_VERSIONS=1

Eric,

Done. See the attached text file. It contains terminal output from both fedora 27 and fedora 30. Let me know if you need something else.
Comment 6 John Ganci CLA 2019-07-11 15:03:10 EDT
(In reply to Eric Williams from comment #1)
> Can someone try to reproduce on Windows or Mac? If not it could be an SWT
> issue.

No problem on my MacBook Pro using eclipse 2019-06.
Comment 7 John Ganci CLA 2019-08-14 12:58:38 EDT
Created attachment 279573 [details]
Picture of screen after move mouse off of help box

Since I couldn't take a screenshot of the problem, I decided to take a picture of the screen after moving the mouse off of the help box. Also, not that it should matter, but my screen resolution is 1600x1200.
Comment 8 Eric Williams CLA 2019-08-14 14:28:47 EDT
Did the issue reproduce on Fedora 27 using SWT_WEBKIT2=1?
Comment 9 John Ganci CLA 2019-08-14 15:16:26 EDT
(In reply to Eric Williams from comment #8)
> Did the issue reproduce on Fedora 27 using SWT_WEBKIT2=1?

No. I'm a newbie to bugzilla. I posted my results on 07/11 but not as a reply to you. See comment 5 above. Sorry about that.
Comment 10 Eric Williams CLA 2019-08-14 15:38:27 EDT
(In reply to John Ganci from comment #9)
> (In reply to Eric Williams from comment #8)
> > Did the issue reproduce on Fedora 27 using SWT_WEBKIT2=1?
> 
> No. I'm a newbie to bugzilla. I posted my results on 07/11 but not as a
> reply to you. See comment 5 above. Sorry about that.

No problem, sounds like it's an issue either in WebKitGTK, or GTK itself. I'll look into this during the next release cycle (we are almost at the end of 4.13).
Comment 11 John Ganci CLA 2019-10-29 12:42:23 EDT
Has anything been done about this issue? Writing code in Eclipse on my linux PC has become very frustrating due to this problem.
Comment 12 Eric Williams CLA 2019-10-29 14:38:02 EDT
Do you still have access to the Fedora 27 machine? IIRC Fedora 27 was the last one with WebKit1 installable. What I'm curious to see is if the bug reproduces with both SWT_WEBKIT2=0 and SWT_WEBKIT2=1. The latter you have confirmed, but the former would be good to know.
Comment 13 John Ganci CLA 2019-10-29 19:40:53 EDT
(In reply to Eric Williams from comment #12)
> Do you still have access to the Fedora 27 machine? IIRC Fedora 27 was the
> last one with WebKit1 installable. What I'm curious to see is if the bug
> reproduces with both SWT_WEBKIT2=0 and SWT_WEBKIT2=1. The latter you have
> confirmed, but the former would be good to know.

Yes. At the present time I am considering booting it for all my eclipse work. I am assuming that you are asking me to do as in Comment 4. That is, boot fedora 27, set SWT_WEBKIT2=0 and try to reproduce. Correct?
Comment 14 Eric Williams CLA 2019-10-29 21:36:09 EDT
(In reply to John Ganci from comment #13)
> (In reply to Eric Williams from comment #12)
> > Do you still have access to the Fedora 27 machine? IIRC Fedora 27 was the
> > last one with WebKit1 installable. What I'm curious to see is if the bug
> > reproduces with both SWT_WEBKIT2=0 and SWT_WEBKIT2=1. The latter you have
> > confirmed, but the former would be good to know.
> 
> Yes. At the present time I am considering booting it for all my eclipse
> work. I am assuming that you are asking me to do as in Comment 4. That is,
> boot fedora 27, set SWT_WEBKIT2=0 and try to reproduce. Correct?

Correct. SWT_WEBKIT2=0 will force SWT to use WebKit1.
Comment 15 John Ganci CLA 2019-10-29 22:42:30 EDT
Created attachment 280454 [details]
Terminal output running eclipse on fedora 27 with SWT_WEBKIT2=0

Performed the test. Eclipse behaved as expected. No problems. Same as the SWT_WEBKIT2=1 test run on Fedora 27 done earlier. See the new attachment for the terminal output.
Comment 16 John Ganci CLA 2019-10-29 22:45:03 EDT
(In reply to Eric Williams from comment #14)
> (In reply to John Ganci from comment #13)
> > (In reply to Eric Williams from comment #12)
> > > Do you still have access to the Fedora 27 machine? IIRC Fedora 27 was the
> > > last one with WebKit1 installable. What I'm curious to see is if the bug
> > > reproduces with both SWT_WEBKIT2=0 and SWT_WEBKIT2=1. The latter you have
> > > confirmed, but the former would be good to know.
> > 
> > Yes. At the present time I am considering booting it for all my eclipse
> > work. I am assuming that you are asking me to do as in Comment 4. That is,
> > boot fedora 27, set SWT_WEBKIT2=0 and try to reproduce. Correct?
> 
> Correct. SWT_WEBKIT2=0 will force SWT to use WebKit1.

Well, I did it again. Comment 15, containing the test results, should've been a reply to your Comment 13.
Comment 17 Eric Williams CLA 2019-10-30 08:49:30 EDT
Okay, so we can rule out WebKit being an issue.

Are you running Wayland or X11? You can find out by opening Eclipse, Help -> About -> Installation Details -> Configuration. In the list of values, there will be a key called "org.eclipse.swt.internal.gdk.backend", which will either say "x11" or "wayland". Please post the output of that.
Comment 18 John Ganci CLA 2019-10-30 10:59:24 EDT
(In reply to Eric Williams from comment #17)
> Okay, so we can rule out WebKit being an issue.
> 
> Are you running Wayland or X11? You can find out by opening Eclipse, Help ->
> About -> Installation Details -> Configuration. In the list of values, there
> will be a key called "org.eclipse.swt.internal.gdk.backend", which will
> either say "x11" or "wayland". Please post the output of that.

Neither (fedora 30, eclipse 2019-09) nor (fedora 27, eclipse Photon) had such a key. I did as you said, then searched the configuration data for "org.eclipse.swt.internal". Four occurrences on fedora 30, three occurrences on fedora 27. From a web search I discovered how to determine whether I am running Wayland. (In both cases, I am running Wayland.) The following data is what I saw on fedora 30 and fedora 27.

########## Begin data ##########
Fedora 30, Eclipse 2019-09.

1. Lines from eclipse installation configuration output.

org.eclipse.swt.internal.deviceZoom=100
org.eclipse.swt.internal.gtk.theme=Adwaita
org.eclipse.swt.internal.gtk.version=3.24.11
org.eclipse.swt.internal.webkitgtk.version=2.24.4

2. Terminal output from commands. Replace <UID> with user id.

$ echo $WAYLAND_DISPLAY
wayland-0
$ loginctl show-session `loginctl|grep <UID>|awk '{print $1}'` -p Type
Type=wayland
$ loginctl | grep <UID>
      2 1000 <UID> seat0 tty2
$ loginctl show-session 2 -p Type
Type=wayland
$


Fedora 27. Eclipse Photon (2018-06).

1. Lines from eclipse installation configuration output.

org.eclipse.swt.internal.deviceZoom=100
org.eclipse.swt.internal.gtk.theme=Adwaita
org.eclipse.swt.internal.gtk.version=3.22.26

2. Terminal output from commands. Replace <UID> with user id.

$ echo $WAYLAND_DISPLAY
wayland-0
$ loginctl | grep <UID>
         2       1000 <UID>             seat0            /dev/tty2       
$ loginctl show-session 2 -p Type
Type=wayland
$ 
########## End   data ##########
Comment 19 Eric Williams CLA 2019-10-30 11:46:13 EDT
(In reply to John Ganci from comment #18)
> running Wayland. (In both cases, I am running Wayland.) 

Okay, please try with X11. You can set GDK_BACKEND=x11 before running Eclipse and it will launch Eclipse under X11.

We have some issues with Javadoc popups on Wayland, so I wouldn't be surprised if the issue doesn't reproduce on X11.
Comment 20 John Ganci CLA 2019-10-30 12:22:25 EDT
(In reply to Eric Williams from comment #19)
> (In reply to John Ganci from comment #18)
> > running Wayland. (In both cases, I am running Wayland.) 
> 
> Okay, please try with X11. You can set GDK_BACKEND=x11 before running
> Eclipse and it will launch Eclipse under X11.
> 
> We have some issues with Javadoc popups on Wayland, so I wouldn't be
> surprised if the issue doesn't reproduce on X11.

That seems to eliminate the problem when I run eclipse from a terminal window. When I did the following on fedora 30

$ export GDK_BACKEND=x11
$ eclipse

The hover over KEY_ANTIALIASING, then move mouse resulted in the complete help box disappearing. Also, no more flickering, even when doing other things that cause the problem. (But there is a flicker when eclipse starts. See paragraph at end.) See next paragraph.

If by Javadoc popup issues you mean  doing something like (1) typing something like "JFrame." (2) letting the possible values pop up, (3) getting some flickering and/or sluggishness, (4) entire pop up data not disappearing when selecting one of them, then I am seeing such issues as well. Very annoying when trying to enter code.

The problem remains when I start eclipse from an eclipse icon I normally use to launch it. Is there a way to incorporate something like "GDK_BACKEND=x11" into the graphic launch of eclipse?

Curious that the problem does not occur on Fedora 27.

One odd thing I noticed when doing the export, and starting eclipse, the initial dialog that allows one to change the workspace had a flicker along the bottom line which stopped after about a second. Moving the mouse over the Cancel button resulted in a short flicker; moving the mouse off the Cancel button also resulted in a short flicker. Same thing happened with the Launch button.
Comment 21 John Ganci CLA 2019-10-30 12:28:56 EDT
(In reply to John Ganci from comment #20)
> (In reply to Eric Williams from comment #19)
> > (In reply to John Ganci from comment #18)
> > > running Wayland. (In both cases, I am running Wayland.) 
> > 
> > Okay, please try with X11. You can set GDK_BACKEND=x11 before running
> > Eclipse and it will launch Eclipse under X11.
> > 
> > We have some issues with Javadoc popups on Wayland, so I wouldn't be
> > surprised if the issue doesn't reproduce on X11.
> 
> That seems to eliminate the problem when I run eclipse from a terminal
> window. When I did the following on fedora 30
> 
> $ export GDK_BACKEND=x11
> $ eclipse
> 
> The hover over KEY_ANTIALIASING, then move mouse resulted in the complete
> help box disappearing. Also, no more flickering, even when doing other
> things that cause the problem. (But there is a flicker when eclipse starts.
> See paragraph at end.) See next paragraph.
> 
> If by Javadoc popup issues you mean  doing something like (1) typing
> something like "JFrame." (2) letting the possible values pop up, (3) getting
> some flickering and/or sluggishness, (4) entire pop up data not disappearing
> when selecting one of them, then I am seeing such issues as well. Very
> annoying when trying to enter code.
> 
> The problem remains when I start eclipse from an eclipse icon I normally use
> to launch it. Is there a way to incorporate something like "GDK_BACKEND=x11"
> into the graphic launch of eclipse?
> 
> Curious that the problem does not occur on Fedora 27.
> 
> One odd thing I noticed when doing the export, and starting eclipse, the
> initial dialog that allows one to change the workspace had a flicker along
> the bottom line which stopped after about a second. Moving the mouse over
> the Cancel button resulted in a short flicker; moving the mouse off the
> Cancel button also resulted in a short flicker. Same thing happened with the
> Launch button.

Addendum. When starting eclipse via the icon (so using Wayland), I do NOT see the flickering on the initial dialog box bottom line or the hovering over the Cancel and Launch buttons.
Comment 22 Eric Williams CLA 2019-10-30 12:37:49 EDT
(In reply to John Ganci from comment #20)
> If by Javadoc popup issues you mean  doing something like (1) typing
> something like "JFrame." (2) letting the possible values pop up, (3) getting
> some flickering and/or sluggishness, (4) entire pop up data not disappearing
> when selecting one of them, then I am seeing such issues as well. Very
> annoying when trying to enter code.

Yes, the Javadoc popup machinery on Wayland is finicky, it needs to be looked at and it's on my list.

 
> The problem remains when I start eclipse from an eclipse icon I normally use
> to launch it. Is there a way to incorporate something like "GDK_BACKEND=x11"
> into the graphic launch of eclipse?

How have you installed Eclipse? Or are you running it from a downloaded binary file?

> Curious that the problem does not occur on Fedora 27.

Well Fedora 27/28 had GTK3.22, Fedora 29/30 have GTK3.24. The difference in GTK3 version could have something to do with it. There is a way to check -- I can provide instructions by the end of the day (need to upload some bindings to GitHub for you to download).

 
> One odd thing I noticed when doing the export, and starting eclipse, the
> initial dialog that allows one to change the workspace had a flicker along
> the bottom line which stopped after about a second. Moving the mouse over
> the Cancel button resulted in a short flicker; moving the mouse off the
> Cancel button also resulted in a short flicker. Same thing happened with the
> Launch button.

I have observed this too and I made a mental note about it but haven't filed a bug report. I'll do that today.
Comment 23 John Ganci CLA 2019-10-30 12:56:11 EDT
(In reply to Eric Williams from comment #22)
> (In reply to John Ganci from comment #20)
> > If by Javadoc popup issues you mean  doing something like (1) typing
> > something like "JFrame." (2) letting the possible values pop up, (3) getting
> > some flickering and/or sluggishness, (4) entire pop up data not disappearing
> > when selecting one of them, then I am seeing such issues as well. Very
> > annoying when trying to enter code.
> 
> Yes, the Javadoc popup machinery on Wayland is finicky, it needs to be
> looked at and it's on my list.
> 
>  
> > The problem remains when I start eclipse from an eclipse icon I normally use
> > to launch it. Is there a way to incorporate something like "GDK_BACKEND=x11"
> > into the graphic launch of eclipse?
> 
> How have you installed Eclipse? Or are you running it from a downloaded
> binary file?
> 
> > Curious that the problem does not occur on Fedora 27.
> 
> Well Fedora 27/28 had GTK3.22, Fedora 29/30 have GTK3.24. The difference in
> GTK3 version could have something to do with it. There is a way to check --
> I can provide instructions by the end of the day (need to upload some
> bindings to GitHub for you to download).
> 
>  
> > One odd thing I noticed when doing the export, and starting eclipse, the
> > initial dialog that allows one to change the workspace had a flicker along
> > the bottom line which stopped after about a second. Moving the mouse over
> > the Cancel button resulted in a short flicker; moving the mouse off the
> > Cancel button also resulted in a short flicker. Same thing happened with the
> > Launch button.
> 
> I have observed this too and I made a mental note about it but haven't filed
> a bug report. I'll do that today.

Here's a bummer. I just tried to start eclipse again using x11. It failed!?

Note: output below is after logging out and logging in again.

Console:
-------

$ export GDK_BACKEND=1
$ eclipse
Eclipse: Cannot open display: 
Eclipse: Cannot open display: 
org.eclipse.m2e.logback.configuration: The org.eclipse.m2e.logback.configuration bundle was activated before the state location was initialized.  Will retry after the state location is initialized.
Eclipse: Cannot open display: 
Eclipse:
An error has occurred. See the log file
/home/john/.eclipse/org.eclipse.platform_4.12.0_694179380_linux_gtk_x86_64/configuration/1572453976359.log.
$ 

Log file:
--------

!SESSION 2019-10-30 11:46:16.196 -----------------------------------------------
eclipse.buildId=4.12.0.I20190605-1800
java.version=1.8.0_201
java.vendor=Oracle Corporation
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
Framework arguments:  -product org.eclipse.epp.package.java.product
Command-line arguments:  -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.java.product

!ENTRY org.eclipse.osgi 4 0 2019-10-30 11:46:17.517
!MESSAGE Application error
!STACK 1
org.eclipse.swt.SWTError: No more handles [gtk_init_check() failed]
	at org.eclipse.swt.SWT.error(SWT.java:4725)
	at org.eclipse.swt.widgets.Display.createDisplay(Display.java:1062)
	at org.eclipse.swt.widgets.Display.create(Display.java:1042)
	at org.eclipse.swt.graphics.Device.<init>(Device.java:175)
	at org.eclipse.swt.widgets.Display.<init>(Display.java:608)
	at org.eclipse.swt.widgets.Display.<init>(Display.java:599)
	at org.eclipse.ui.internal.Workbench.createDisplay(Workbench.java:755)
	at org.eclipse.ui.PlatformUI.createDisplay(PlatformUI.java:162)
	at org.eclipse.ui.internal.ide.application.IDEApplication.createDisplay(IDEApplication.java:185)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:128)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:137)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:107)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:660)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:597)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1468)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1441)
########## End log ##########
Comment 24 John Ganci CLA 2019-10-30 13:02:36 EDT
(In reply to John Ganci from comment #23)
> (In reply to Eric Williams from comment #22)
> > (In reply to John Ganci from comment #20)
> > > If by Javadoc popup issues you mean  doing something like (1) typing
> > > something like "JFrame." (2) letting the possible values pop up, (3) getting
> > > some flickering and/or sluggishness, (4) entire pop up data not disappearing
> > > when selecting one of them, then I am seeing such issues as well. Very
> > > annoying when trying to enter code.
> > 
> > Yes, the Javadoc popup machinery on Wayland is finicky, it needs to be
> > looked at and it's on my list.
> > 
> >  
> > > The problem remains when I start eclipse from an eclipse icon I normally use
> > > to launch it. Is there a way to incorporate something like "GDK_BACKEND=x11"
> > > into the graphic launch of eclipse?
> > 
> > How have you installed Eclipse? Or are you running it from a downloaded
> > binary file?
> > 
> > > Curious that the problem does not occur on Fedora 27.
> > 
> > Well Fedora 27/28 had GTK3.22, Fedora 29/30 have GTK3.24. The difference in
> > GTK3 version could have something to do with it. There is a way to check --
> > I can provide instructions by the end of the day (need to upload some
> > bindings to GitHub for you to download).
> > 
> >  
> > > One odd thing I noticed when doing the export, and starting eclipse, the
> > > initial dialog that allows one to change the workspace had a flicker along
> > > the bottom line which stopped after about a second. Moving the mouse over
> > > the Cancel button resulted in a short flicker; moving the mouse off the
> > > Cancel button also resulted in a short flicker. Same thing happened with the
> > > Launch button.
> > 
> > I have observed this too and I made a mental note about it but haven't filed
> > a bug report. I'll do that today.
> 
> Here's a bummer. I just tried to start eclipse again using x11. It failed!?
> 
> Note: output below is after logging out and logging in again.
> 
> Console:
> -------
> 
> $ export GDK_BACKEND=1
> $ eclipse
> Eclipse: Cannot open display: 
> Eclipse: Cannot open display: 
> org.eclipse.m2e.logback.configuration: The
> org.eclipse.m2e.logback.configuration bundle was activated before the state
> location was initialized.  Will retry after the state location is
> initialized.
> Eclipse: Cannot open display: 
> Eclipse:
> An error has occurred. See the log file
> /home/john/.eclipse/org.eclipse.platform_4.12.0_694179380_linux_gtk_x86_64/
> configuration/1572453976359.log.
> $ 
> 
> Log file:
> --------
> 
> !SESSION 2019-10-30 11:46:16.196
> -----------------------------------------------
> eclipse.buildId=4.12.0.I20190605-1800
> java.version=1.8.0_201
> java.vendor=Oracle Corporation
> BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
> Framework arguments:  -product org.eclipse.epp.package.java.product
> Command-line arguments:  -os linux -ws gtk -arch x86_64 -product
> org.eclipse.epp.package.java.product
> 
> !ENTRY org.eclipse.osgi 4 0 2019-10-30 11:46:17.517
> !MESSAGE Application error
> !STACK 1
> org.eclipse.swt.SWTError: No more handles [gtk_init_check() failed]
> 	at org.eclipse.swt.SWT.error(SWT.java:4725)
> 	at org.eclipse.swt.widgets.Display.createDisplay(Display.java:1062)
> 	at org.eclipse.swt.widgets.Display.create(Display.java:1042)
> 	at org.eclipse.swt.graphics.Device.<init>(Device.java:175)
> 	at org.eclipse.swt.widgets.Display.<init>(Display.java:608)
> 	at org.eclipse.swt.widgets.Display.<init>(Display.java:599)
> 	at org.eclipse.ui.internal.Workbench.createDisplay(Workbench.java:755)
> 	at org.eclipse.ui.PlatformUI.createDisplay(PlatformUI.java:162)
> 	at
> org.eclipse.ui.internal.ide.application.IDEApplication.
> createDisplay(IDEApplication.java:185)
> 	at
> org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.
> java:128)
> 	at
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:
> 203)
> 	at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.
> runApplication(EclipseAppLauncher.java:137)
> 	at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.
> start(EclipseAppLauncher.java:107)
> 	at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400)
> 	at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.
> java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:660)
> 	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:597)
> 	at org.eclipse.equinox.launcher.Main.run(Main.java:1468)
> 	at org.eclipse.equinox.launcher.Main.main(Main.java:1441)
> ########## End log ##########

Never mind. I enterd the wrong value when setting GDK_BACKEND. My bad. Sorry about that.
Comment 25 John Ganci CLA 2019-10-30 13:44:17 EDT
(In reply to Eric Williams from comment #22)
> (In reply to John Ganci from comment #20)
> > If by Javadoc popup issues you mean  doing something like (1) typing
> > something like "JFrame." (2) letting the possible values pop up, (3) getting
> > some flickering and/or sluggishness, (4) entire pop up data not disappearing
> > when selecting one of them, then I am seeing such issues as well. Very
> > annoying when trying to enter code.
> 
> Yes, the Javadoc popup machinery on Wayland is finicky, it needs to be
> looked at and it's on my list.
> 
>  
> > The problem remains when I start eclipse from an eclipse icon I normally use
> > to launch it. Is there a way to incorporate something like "GDK_BACKEND=x11"
> > into the graphic launch of eclipse?
> 
> How have you installed Eclipse? Or are you running it from a downloaded
> binary file?

For each install I perform the following steps. (Step 4 was only done once.)

1. Download the tar.gz file; current one is eclipse-java-2019-06-R-linux-gtk-x86_64.tar.gz.

2. Have an eclipse directory on a separate partition (which is listed in my /etc/fstab file). The downloaded file is untarred in the eclipse directory. Currently I have /eclipse/eclipse-2019-06/ there, as well as previous versions (oxygen and proton). in case I want to switch back to one of them.

3. In the /usr/local subdirectory I create a logical link to the "current" Eclipse. "ls -l /usr/local" output follows. You'll note that I handle Java similarly. (Actual steps here: (1) delete existing eclipse logical link; (2) create new eclipse logical link.)

...
lrwxrwxrwx. 1 root root   46 Jun 29 08:44 eclipse -> /mnt/additions/eclipse/eclipse-2019-06/eclipse
...
lrwxrwxrwx. 1 root root   32 Jun 14 12:10 java -> /mnt/additions/java/jdk1.8.0_201
...

4. My .bash_profile updates the $PATH environment variable to contain /usr/local/eclipse (and /usr/local/java), so no change is required -- the logical link change takes care of pointing to the "current" eclipse.


> 
> > Curious that the problem does not occur on Fedora 27.
> 
> Well Fedora 27/28 had GTK3.22, Fedora 29/30 have GTK3.24. The difference in
> GTK3 version could have something to do with it. There is a way to check --
> I can provide instructions by the end of the day (need to upload some
> bindings to GitHub for you to download).
>

While this would be nice, you don't have to do this. I suspect that I'm not smart enough to perform whatever tasks would be required.

 
>  
> > One odd thing I noticed when doing the export, and starting eclipse, the
> > initial dialog that allows one to change the workspace had a flicker along
> > the bottom line which stopped after about a second. Moving the mouse over
> > the Cancel button resulted in a short flicker; moving the mouse off the
> > Cancel button also resulted in a short flicker. Same thing happened with the
> > Launch button.
> 
> I have observed this too and I made a mental note about it but haven't filed
> a bug report. I'll do that today.


That's great.
Comment 26 Eric Williams CLA 2019-10-31 14:08:47 EDT
(In reply to John Ganci from comment #25)
> (In reply to Eric Williams from comment #22)
> > (In reply to John Ganci from comment #20)
> > > If by Javadoc popup issues you mean  doing something like (1) typing
> > > something like "JFrame." (2) letting the possible values pop up, (3) getting
> > > some flickering and/or sluggishness, (4) entire pop up data not disappearing
> > > when selecting one of them, then I am seeing such issues as well. Very
> > > annoying when trying to enter code.
> > 
> > Yes, the Javadoc popup machinery on Wayland is finicky, it needs to be
> > looked at and it's on my list.
> > 
> >  
> > > The problem remains when I start eclipse from an eclipse icon I normally use
> > > to launch it. Is there a way to incorporate something like "GDK_BACKEND=x11"
> > > into the graphic launch of eclipse?
> > 
> > How have you installed Eclipse? Or are you running it from a downloaded
> > binary file?
> 
> For each install I perform the following steps. (Step 4 was only done once.)
> 
> 1. Download the tar.gz file; current one is
> eclipse-java-2019-06-R-linux-gtk-x86_64.tar.gz.
> 
> 2. Have an eclipse directory on a separate partition (which is listed in my
> /etc/fstab file). The downloaded file is untarred in the eclipse directory.
> Currently I have /eclipse/eclipse-2019-06/ there, as well as previous
> versions (oxygen and proton). in case I want to switch back to one of them.
> 
> 3. In the /usr/local subdirectory I create a logical link to the "current"
> Eclipse. "ls -l /usr/local" output follows. You'll note that I handle Java
> similarly. (Actual steps here: (1) delete existing eclipse logical link; (2)
> create new eclipse logical link.)
> 
> ...
> lrwxrwxrwx. 1 root root   46 Jun 29 08:44 eclipse ->
> /mnt/additions/eclipse/eclipse-2019-06/eclipse
> ...
> lrwxrwxrwx. 1 root root   32 Jun 14 12:10 java ->
> /mnt/additions/java/jdk1.8.0_201
> ...
> 
> 4. My .bash_profile updates the $PATH environment variable to contain
> /usr/local/eclipse (and /usr/local/java), so no change is required -- the
> logical link change takes care of pointing to the "current" eclipse.

Is there a script you could run in the place of Eclipse, that would set GDK_BACKEND=x11 and then launch the binary? Alternatively, you can run your entire GNOME session on x11. If you click the cogwheel icon at the login screen, there should be an option for "GNOME on Xorg".


> > > Curious that the problem does not occur on Fedora 27.
> > 
> > Well Fedora 27/28 had GTK3.22, Fedora 29/30 have GTK3.24. The difference in
> > GTK3 version could have something to do with it. There is a way to check --
> > I can provide instructions by the end of the day (need to upload some
> > bindings to GitHub for you to download).
> >
> 
> While this would be nice, you don't have to do this. I suspect that I'm not
> smart enough to perform whatever tasks would be required.

Not at all! It's quite straightforward.

1) Clone this repo: https://gitlab.com/ericwill/swt-development-tools
2) Identify which GTK3 version you want to run Eclipse on (3.22.30 in this case)
3) Set LD_LIBRARY_PATH=<path_to_git_repo>/linux/gtk_builds/fedora/3.22.30
4) Launch Eclipse

Eclipse should now run on GTK3.22.30. You can do this on Fedora 30 to see if the bug reproduces. You can try it combined with GDK_BACKEND to test both X11 and Wayland.
Comment 27 John Ganci CLA 2019-10-31 14:44:00 EDT
(In reply to Eric Williams from comment #26)
> (In reply to John Ganci from comment #25)
> > (In reply to Eric Williams from comment #22)
> > > (In reply to John Ganci from comment #20)

<Snip down to your first reply.>

> > 4. My .bash_profile updates the $PATH environment variable to contain
> > /usr/local/eclipse (and /usr/local/java), so no change is required -- the
> > logical link change takes care of pointing to the "current" eclipse.
> 
> Is there a script you could run in the place of Eclipse, that would set
> GDK_BACKEND=x11 and then launch the binary? Alternatively, you can run your
> entire GNOME session on x11. If you click the cogwheel icon at the login
> screen, there should be an option for "GNOME on Xorg".
> 

While doing my morning walk, I remembered that there was a way to pick x11 but I did not remember the details. Yes, the cogwheel. (I don't remember why, but sometime ago I had another issue, I think with JavaFX, that I was trying to debug. I stumbled on the cogwheel at that time. That issue, dealing with animation timers running wild on fedora, did result in a Oracle creating a bug for it. If you're curious, look at
  https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8211059
But I digress.) I'll consider one of these two alternatives -- script or cogwheel.

<More snip to your next reply.>

> > While this would be nice, you don't have to do this. I suspect that I'm not
> > smart enough to perform whatever tasks would be required.
> 
> Not at all! It's quite straightforward.
> 
> 1) Clone this repo: https://gitlab.com/ericwill/swt-development-tools
> 2) Identify which GTK3 version you want to run Eclipse on (3.22.30 in this
> case)
> 3) Set LD_LIBRARY_PATH=<path_to_git_repo>/linux/gtk_builds/fedora/3.22.30
> 4) Launch Eclipse
> 
> Eclipse should now run on GTK3.22.30. You can do this on Fedora 30 to see if
> the bug reproduces. You can try it combined with GDK_BACKEND to test both
> X11 and Wayland.

Straightforward for you maybe. While I've accessed github to get libraries for Arduino, I'm not comfortable just diving in to using gitlab without understanding what I'm doing. I'll defer "cloning" what you added until I read up on how to use github and gitlab. I do understand what "clone this repo" means, but I don't know what it does to my PC. I'll look for a youtube tutorial on github and gitlab.
Comment 28 Eric Williams CLA 2019-10-31 15:28:51 EDT
(In reply to John Ganci from comment #27)
> Straightforward for you maybe. While I've accessed github to get libraries
> for Arduino, I'm not comfortable just diving in to using gitlab without
> understanding what I'm doing. I'll defer "cloning" what you added until I
> read up on how to use github and gitlab. I do understand what "clone this
> repo" means, but I don't know what it does to my PC. I'll look for a youtube
> tutorial on github and gitlab.

Okay, no problem. If cloning is an issue you can also download a zip file from the GitLab repo site. If you navigate to the website I linked earlier there should be a download icon on the right, about halfway down the page. Then just extract the zip and launch Eclipse as described.

In the next few days I'll switch to Wayland on my machine and try to reproduce the bug concretely.
Comment 29 John Ganci CLA 2020-03-22 00:10:38 EDT
Just installed eclipse 2020-03. Problem still exists.