Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Eclipse Hover loses control in certain cases #2534

Closed
mehmet-karaman opened this issue Nov 25, 2024 · 2 comments
Closed

Eclipse Hover loses control in certain cases #2534

mehmet-karaman opened this issue Nov 25, 2024 · 2 comments
Assignees
Labels
bug Something isn't working
Milestone

Comments

@mehmet-karaman
Copy link
Contributor

Steps to reproduce

From a fresh installation and clean workspace:

  • Create a new Java Project and open a java class in the java editor
  • Move the mouse to a place where the hover shows up. (eg. Class head and hover on the class name)
  • Double click on the Hover
  • Minimize the Eclipse window and show it back.
  • Move any other applications window to the foreground
  • The hover is still visible above the foreign windows

I expected:

The Sticky hover shouldn't be visible (closed when focus is lost)

But got:

Sticky hover is still there

Tested with Eclipse Version:

Version: 2024-12 (4.34)
Build id: I20241022-1800

Here is a video recorded in windows:

Hover_looses_listeners_and_dont_reacts_anymore_720.mp4
@mehmet-karaman mehmet-karaman added the bug Something isn't working label Nov 25, 2024
@iloveeclipse
Copy link
Member

Reproducible with latest 4.34 RC2 on RHEL 9.2 too, so this is not Windows specific.

mehmet-karaman added a commit to mehmet-karaman/eclipse.platform.ui that referenced this issue Nov 25, 2024
…lipse-platform#2534

This patch is fixing the problem, where the HoverManagers listeners are
deregistered but the hover is still visibile on top. This happens when
the hover was sticky eclipse was minimized and put back on foreground
after it. In that case the listeners are already deregistered and there
is no chance to react at all. So for this case the visibility has to be
set explicitly when the close is going to stop.
mehmet-karaman added a commit to mehmet-karaman/eclipse.platform.ui that referenced this issue Nov 25, 2024
…lipse-platform#2534

This patch is fixing the problem, where the HoverManagers listeners are
deregistered but the hover is still visibile on top. This happens when
the hover was sticky eclipse was minimized and put back on foreground
after it. In that case the listeners are already deregistered and there
is no chance to react at all. So for this case the visibility has to be
set explicitly when the close is going to stop.
mehmet-karaman added a commit to mehmet-karaman/eclipse.platform.ui that referenced this issue Nov 25, 2024
…lipse-platform#2534

This patch is fixing the problem, where the HoverManagers listeners are
deregistered but the hover is still visibile on top. This happens when
the hover was sticky eclipse was minimized and put back on foreground
after it. In that case the listeners are already deregistered and there
is no chance to react at all. So for this case the visibility has to be
set explicitly when the close is going to stop.
Version bump(s) for 4.35 stream
Bugfix for Hover which is visible above other application windows. eclipse-platform#2534
mehmet-karaman added a commit to mehmet-karaman/eclipse.platform.ui that referenced this issue Nov 26, 2024
…lipse-platform#2534

This patch is fixing the problem, where the HoverManagers listeners are
deregistered but the hover is still visibile on top. This happens when
the hover was sticky eclipse was minimized and put back on foreground
after it. In that case the listeners are already deregistered and there
is no chance to react at all. So for this case the visibility has to be
set explicitly when the close is going to stop.
Version bump(s) for 4.35 stream
Bugfix for Hover which is visible above other application windows. eclipse-platform#2534
mehmet-karaman added a commit to mehmet-karaman/eclipse.platform.ui that referenced this issue Nov 26, 2024
…lipse-platform#2534

This patch is fixing the problem, where the HoverManagers listeners are
deregistered but the hover is still visibile on top. This happens when
the hover was sticky eclipse was minimized and put back on foreground
after it. In that case the listeners are already deregistered and there
is no chance to react at all. So for this case the visibility has to be
set explicitly when the close is going to stop.
Version bump(s) for 4.35 stream
Bugfix for Hover which is visible above other application windows. eclipse-platform#2534
mehmet-karaman added a commit to mehmet-karaman/eclipse.platform.ui that referenced this issue Nov 26, 2024
…lipse-platform#2534

This patch is fixing the problem, where the HoverManagers listeners are
deregistered but the hover is still visibile on top. This happens when
the hover was sticky eclipse was minimized and put back on foreground
after it. THe shell visibility was set to false explicitly.

Originally the isVisible() was returning false and it won't be set to
visible explicitly.

Version bump(s) for 4.35 stream
iloveeclipse pushed a commit to mehmet-karaman/eclipse.platform.ui that referenced this issue Nov 26, 2024
…lipse-platform#2534

This patch is fixing the problem, where the HoverManagers listeners are
deregistered but the hover is still visibile on top. This happens when
the hover was sticky eclipse was minimized and put back on foreground
after it. THe shell visibility was set to false explicitly.

Originally the isVisible() was returning false and it won't be set to
visible explicitly.

Version bump(s) for 4.35 stream
iloveeclipse pushed a commit that referenced this issue Nov 27, 2024


This patch is fixing the problem, where the HoverManagers listeners are
deregistered but the hover is still visibile on top. This happens when
the hover was sticky eclipse was minimized and put back on foreground
after it. THe shell visibility was set to false explicitly.

Originally the isVisible() was returning false and it won't be set to
visible explicitly.

Version bump(s) for 4.35 stream
@mehmet-karaman
Copy link
Contributor Author

The PR Was merged, so we can close this bug ticket now.

PR: #2540

@iloveeclipse iloveeclipse added this to the 4.35 M1 milestone Dec 2, 2024
mai-tran-03 pushed a commit to mai-tran-03/eclipse.platform.ui that referenced this issue Dec 10, 2024
…lipse-platform#2534

This patch is fixing the problem, where the HoverManagers listeners are
deregistered but the hover is still visibile on top. This happens when
the hover was sticky eclipse was minimized and put back on foreground
after it. THe shell visibility was set to false explicitly.

Originally the isVisible() was returning false and it won't be set to
visible explicitly.

Version bump(s) for 4.35 stream
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants