Flickering hover popup on mouse-over

[FlorianKroiss]

Possibly the same cause as #1445, but a different symptom.

It is a bit hard to see in the video, because the frame-rate is not high enough, but after 0:03, the popup seems to be opened/closed a lot of times and only stays open after a few seconds:

Hover.mp4

[sebthom]

I cannot reproduce this. Can you track down since which version of LSP4E you are facing that issue? The async hover behaviour was introduced in LSP4E 0.28.0

[FlorianKroiss]

@sebthom thanks for taking a look at this.
I was able to go back to 0.27.4, where this bug was already present. I had trouble going back any further (I think because parts of the Target Platform could not be resolved, i.e., they were pointing to the latest URL, which now no longer matches up when trying to build older versions of LSP4E). So this bug could be a quite old.

I will try to take a closer look at it. I was also able to create a better recording of this bug:

2025-12-11.15-53-08.mp4

[FlorianKroiss]

This might be much worse than I thought, at least for the use-case in our product.

Steps to reproduce:

1. Install basedpyright with your favorite python package manager.
2. Create an External Tool Launch Config to launch basedpyright, with Location similar to C:\dev\test-uv\.venv\Scripts\basedpyright-langserver.exe, depending on where you installed the tool. Arguments are --stdio
3. Open Preferences > General > Content Types. Add a Content Type Child beneath "Text" called "Python". Add file association "*.py"
4. Open Preferences > Language Servers. Click "Add..." and bind Content-Type "Python" to the created launch config
5. Create test.py in a Project and open it.
6. Start typing random characters. After every character, the completion proposal dialog pops up.
7. Type a few hundred characters
8. Now hover over the Proposal Detail Popup.
9. The popup is closed and reopened a lot of times, while also blocking the UI thread.
10. Closing and reopening the editor does NOT resolve this.

Performing these steps leads to the behavior captured in the video of my previous comment.

I already did some debugging and I'm almost certain that this is not a problem of LSP4E but a bug in Platform.UI.

Every time the completions popup is shown, a PopupCloser is added as a filter on the current Display, which listens for various mouse events and tries to replace the detail popup, once the mouse hover over it. However, this PopupCloser is not properly removed when the completions popup is closed. Since the completions popup is closed and reopenend after every typed character, we end up with a massive amount of Filters on the Display. As soon as the mouse enters the detail popup, every added filter is triggered and reopens the popup. This only gets worse, the more characters are typed.

Filter Table of the Display after a while. Most of the other filters not visible are also PopupCloser:

The code for handling Popups looks quite complicated to me, but two locations look especially suspicious to me:

https://github.com/eclipse-platform/eclipse.platform.ui/blob/e15e9bf606114f83531019524f3dca21ed351476/bundles/org.eclipse.jface.text/src/org/eclipse/jface/text/contentassist/AsyncCompletionProposalPopup.java#L333-L340
When the completions are updated, the shell is directly disposed. I think hide() should be called here?

https://github.com/eclipse-platform/eclipse.platform.ui/blob/e15e9bf606114f83531019524f3dca21ed351476/bundles/org.eclipse.jface.text/src/org/eclipse/jface/text/contentassist/CompletionProposalPopup.java#L1112-L1120
The uninstallation of the PopupCloser is only called if the popup shell is still valid. But if the shell was disposed any other way (see above code), then the PopupCloser has no way to cleanup the filters that it added to the Display. I think uninstall should always be called, because the PopupCloser has its own checks, if the Shell or the Display are still valid.

I will open an issue with Platform.UI
I would also be grateful if someone else can take a second look at this.

Side note: Debugging Focus Related code is really annoying, because as soon as you interact with your Debugger/IDE, you trigger FocusLost events. Is there a better way to do this, besides using separate Machines/VMs for running the Application and Debugging?

[jonahgraham]

There is a better way, in my experience using a separate x server and running the Eclipse being debugged in it means that you can avoid all such unintended events.

You can also do it with a vm and remote debugging (or a second machine)

Coincidentally I have been recently trying to record some of this in my blog https://kichwacoders.com/blog/ - my purpose is different than yours, but it may be helpful to you. Please feel free to ask me questions on this and I can try to help.

[jonahgraham]

See specifically X11 VNC Server section in https://kichwacoders.com/2025/09/30/testing-and-developing-swt-on-gtk/

[FlorianKroiss]

Thanks for the advice @jonahgraham, but unfortunately I'm stuck with a Windows machine for developing.
I know that WSL supports X11/Wayland to some degree, so maybe I can figure out how to plumb things through there, or I just have to stick to VM for now.