-
Notifications
You must be signed in to change notification settings - Fork 196
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
Comments
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
The PR Was merged, so we can close this bug ticket now. PR: #2540 |
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
Steps to reproduce
From a fresh installation and clean workspace:
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
The text was updated successfully, but these errors were encountered: