Editor popup disappears too soon

I think this issue might be related to Wayland (in Linux) because I've just started using the Wayland session in Gnome 42 and I've never experienced this problem before: when I Ctrl+click on a type in the editor and the popup for "Open declaration"/"Open implementation" appears, it becomes nearly impossible to select "Open implementation" (the second item) because the popup disappears (most of the time) when you move the mouse to select the menu. And this happens in Fedora, Arch and Ubuntu (latest versions, Gnome 42, all with Wayland session).

The version of Eclipse is 2022-03 (4.23.0) but it also happens in 2022-06 M3

I had reported on JDT UI eclipse-jdt/eclipse.jdt.ui#72 but they told me this is the right place.

I confirm it only happens with Wayland: if you start Eclipse with GDK_BACKEND=x11 the popup behaves correctly

@joel-majano

@joel-majano Would you please look into this one?

I'm able to reproduce this in my environment. I'll begin investigating.

@joel-majano

@joel-majano From my experiments i found that you have more chances to succeed to use the pop-up if you control click from near the bottom of the type in the editor

Still an issue with gnome 23.0 ; this issue is not a recent regression, as it exists since eclipse supports wayland.

Not sure if it is related, but javadoc popups also disappears too soon (F2 key to trigger focus works, but moving cursor from symbol to popup to focus it is highly inconsistent).

These two issues are the last ones that make me still run eclipse with GDK_BACKEND=x11.

Here is two screen capture, same gnome 43.0 session (wayland). Same workspace, same eclipse instance, x11 started with GDK_BACKEND=x11, wayland started with GDK_BACKEND=wayland.

With x11, mouse cursor can move reliably from hyperlink to popup.
With wayland, behavior is highly inconsistent ; same cursor movement randomly triggers expected behavior or popup hiding.

I try to search in jdt ui or eclipse text editor where swt components are managed, to see how cursor movement is expected to work so that it does not close popup when mouse flies hover the empty gap between hyperlink and popup (timer, transparent widget, ...). As eclipse is highly modularized, I do not find it. May someone help me to locate this code, so I try to understand the issue ?

eclipse-x11.webm

eclipse-wayland.webm

This is still an issue with eclipse 2023.03 / Fedora 37 / Gnome 43.4. I do not find any workaround to make it working with wayland : popup too frequently closes before cursor can reach it.

I think I find a workaround. With GDK_BACKEND=wayland GTK_DEBUG=interactive environment variable, I find that disabling animation (Visual > Enable animations > Off) allows a much better popup behavior. I can now almost always switch from editor to popup content (Open declaration, implementation, ... menu and javadoc popup).

The only way I find to make it permanent in a gnome-shell environment is to switch gnome-shell settings.

gsettings set org.gnome.desktop.interface enable-animations false

This workaround makes eclipse in a Fedora 38 / Eclipse 4.27 / wayland environment usable with the WEBKIT_DISABLE_COMPOSITING_MODE=1 (to solve empty javadoc popup workaround).

I hope this workaround may help to fix this issue. If anyone knows how to turn off animation only for eclipse and not all the gnome desktop applications, I would be grateful to hear it.

I'm late on this train but it is also the main annoyance with Wayland in my opinion.
I imagine it's possible to combine https://askubuntu.com/a/1063651 and https://stackoverflow.com/a/54160420/2427750 to create a file

[Settings]
gtk-enable-animations=0

in eg your eclipse installation folder
and then run Eclipse IDE with XDG_CONFIG_HOME=/path/to/eclipse/install/gtk-settings.ini ./eclipse. You can then tweak the .desktop file, or some script or some alias you like to use to avoid repeating the setting.
HTH

Unfortunately this does not work. As I understand it, gtk contextually uses other settings sources when available, so settings.ini is ignored.

Seems consistent with this : https://gitlab.gnome.org/GNOME/gtk/-/blob/3.24.36/gdk/wayland/gdkscreen-wayland.c#L717 ; gtk settings uses xdg-portal (can be disabled by GTK_USE_PORTAL) and dbus (I don't find a way to disable it ; DBUS_SESSION_BUS_ADDRESS= does not seem to be enough to isolate gtk from dbus) with a higher priority.

Interested if anyone has a clue to force gtk to use settings.ini.

After some testing, I think that animations enabled/disabled has no effect on the issue.

I think that GTK_DEBUG=interactive implies some latency that lightly improves the issue, and that I don't check enough gsettings preference switch, as a second-pass shows me a still inconsistent behavior.

I think I find the code that is responsible for displaying this component : org.eclipse.jface.text.hyperlink.MultipleHyperlinkPresenter.

Unexpected closing event for popup is triggered by org.eclipse.jface.text.hyperlink.MultipleHyperlinkPresenter.MultipleHyperlinkHoverManager.Closer.inKeepUpZone(int, int, Rectangle) https://github.com/eclipse-platform/eclipse.platform.text/blob/97118f518229900979c04bf0c5bb906a6448ebaf/org.eclipse.jface.text/src/org/eclipse/jface/text/hyperlink/MultipleHyperlinkPresenter.java#L485 ; x, y coordinates seem buggy, as they are negative (as coordinates are supposed to be relative to text editor, this values are unexpected).

From my investigation, wrong coordinates are extracted here :

org.eclipse.swt.widgets.Control.gtk_motion_notify_event(long, long) with is_hint == true /

eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Control.java

Line 4244 in 2b9b6b4

if (isHint) {
org.eclipse.swt.widgets.Display.getWindowPointerPosition(long, int[], int[], int[])

eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Display.java

Line 6196 in 2b9b6b4

long getWindowPointerPosition(long window, int[] x, int[] y, int[] mask) {
it seems to be a known issue that gtk3 + wayland gives unexpected results because window positioning with gtk3 is hacky (https://gitlab.gnome.org/GNOME/gtk/-/issues/1708) but the explanation given on this issue does not explain the negative values I obtain.

In org.eclipse.swt.widgets.Control.gtk_motion_notify_event(long, long) :

if I drop isHint block, things get worse (popup is blinking, i.e. it closes for each mouse move)
if I cancel event (return 0) is both x and y are negative, popup behavior is OK

Sadly, not a workaround. I perform further testing, and « wrong » position varies, and x value becomes positive if both the label is long enough (for example ScheduledExecutor) and mouse moves on the right side of the label.

For the moment I try to understand if this « buggy » position makes sense to check :

if it is really a bug ; maybe I do not understand GTK API
if it is a bug, is there a way to reliably ignore it

(learning both SWT and GTK, so it is kind of uneasy).

Fix getWindowPointerPosition on Wayland eclipse-platform#177

Experiencing the same issue on Arch Linux, KDE Plasma and Eclipse 2024-03

I seem to understand that it also happens in Gnome, though less frequently

Still an issue on Fedora 39 / Gnome shell / Wayland / Eclipse 2024-03. Same buggy behavior observed. Still difficult to use ctrl+hover menu (Open declaration, Open implementation, ...) as shown in previous video.

Fedora 39 / Gnome shell / Wayland / Eclipse 2024-03 GDK_BACKEND=x11 is OK.

I just see that there's some work on the issue and a PR #960 opened.

I give a try to the PR #960 and it fixes the issue. Hoping that it may be merged for the next Eclipse release.

Fix getWindowPointerPosition on Wayland eclipse-platform#177

Fix getWindowPointerPosition on Wayland #177

@akurtakov

@akurtakov thanks for fixing this!
Is it already available or should I wait for the next milestone?

It should be in the latest I-build.

Navigation Menu

Repository navigation

Editor popup disappears too soon #177

1 remaining item

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Editor popup disappears too soon #177

Description

Activity

LorenzoBettini commented on Jun 6, 2022

akurtakov commented on Jun 7, 2022

joel-majano commented on Jun 7, 2022

LorenzoBettini commented on Jun 7, 2022

lalmeras commented on Oct 29, 2022

lalmeras commented on Nov 1, 2022

lalmeras commented on Apr 27, 2023

lalmeras commented on Apr 29, 2023

mickaelistria commented on May 4, 2023

lalmeras commented on May 6, 2023

lalmeras commented on May 7, 2023

lalmeras commented on May 8, 2023

lalmeras commented on May 8, 2023

1 remaining item

lalmeras commented on May 9, 2023

ArthurBorsboom commented on Mar 25, 2024

LorenzoBettini commented on Mar 25, 2024

lalmeras commented on Mar 25, 2024

lalmeras commented on Mar 27, 2024

LorenzoBettini commented on May 13, 2024

akurtakov commented on May 13, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions