eclipse.platform.swt
eclipse.platform.swt copied to clipboard
Win: Eclipse IDE freeze with Hover across screens with different UI scaling
Describe the bug Eclipse IDE is hanging for ever if a long Hover Text is shown across multiple screens, 100% reproducible on some eclipse installations, but does not occur on other eclipse installations with same eclipse version on same computer - i could not find the difference.
To Reproduce Use windows 10. Have 2 Screens. Left configured to 100% and right configured to 125% UI Scaling in Windows setting.
Having a Class
class Long {
public void veryLongMethodName1veryLongMethodName2veryLongMethodName3veryLongMethodName4() {
}
}
And Show the Outline, Hover the method name with the mouse.
The freeze ends as soon as the second display is changed back to 100%.
Sampling shows, that the CPU is busy and debugging shows Windows OS sends Events again and again and SWT is doing some things, but the hover text is never shown.

Expected behavior No freeze.
Version since First seen in Eclipse 4.26
Workaround Use 100% UI Scaling on all Monitors.
Ideas welcome. It feels like Windows/SWT is not sure which scaling to use and is hung in an endless resizing loop.
Looks like a Microsoft Windows OS bug: According to https://learn.microsoft.com/de-de/windows/win32/controls/ttn-show "SetWindowPos" should be called when TTN_SHOW is received. And that's what SWT does in org.eclipse.swt.widgets.Tree.wmNotifyToolTip(NMHDR, long, long). When i replace SetWindowPos with "return null" while SWT is in that endless loop, then the quickinfo text is not shown and the endless "windowProc" events stop.
I would suspect that SWT calls some kind of redraw(), or maybe it sets different size with SetWindowPos(), which causes Tooltip to endlessly repaint.
SetWindowPos always gets the same coordinates. Where could i see some kind of redraw()?
I meant Control.redraw() which calls OS.RedrawWindow(), but it could aslo be OS.InvalidateRect(), showing and hiding, etc. Anything that could trigger tooltip to repaint.
OS.RedrawWindow(), but it could aslo beOS.InvalidateRect(),
none of those is called during the endless events
Please reduce this to an SWT snippet and I could have a look and figure why these "endless" events are sent. It's quite likely that there will be an SWT problem right there on stack.
Snippet125 is a bit similar, but does not show the problem. A difference is that the outline view which shows the error not only renders text but a symbol+text as tooltip. That's beyond my swt skils - I am not able to extract an SWT snippet for this :-(
Curios, so some special conditions are needed. Probably the problem lurks there. If time allows, I'll try to extract snippet. It's not that I have too much time to look at problems that are not present in our product, so it would still be best if someone else handles the snippet part and I'll only do the complicated debugging part.
Not reproducible for me with Eclipse 2022-12:

Curiously for the first time tooltip is shown,it shows at different DPI.
I also tried a number of other DPI combinations and the problem is still not reproducible: 100/150%, 100/175%, 125/100%, 150/100%, 150/125%
I also tried these steps on Win10 and also didn't reproduce. I'm beginning to suspect 3rd party software.
Thanks for trying tho.
Curiously for the first time tooltip is shown,it shows at different DPI.
Interesting i have never seen that. Either l had a freeze (two different computers) or no problem at all (other eclipse installation).
If you're willing to do some debugging with native debugger, I could explain how. It's going to be simple enough to just follow the steps.
We've also encountered something similar in an RCP-based application, here a table cell's native tooltip extending over the edge triggers this behavior. The problem display on the left is set to 100% and the display to its right is at 150% scale. SWT version is org.eclipse.swt_3.115.0.v20200831-1002, OS is Windows 11 23H2. The main thread's call stack looks like the following:
at org.eclipse.swt.internal.win32.OS.CallWindowProc(JJIJJ)J (Native Method)
at org.eclipse.swt.widgets.Table.callWindowProc(JIJJZ)J (Table.java:588)
at org.eclipse.swt.widgets.Table.callWindowProc(JIJJ)J (Table.java:454)
at org.eclipse.swt.widgets.Table.wmNotifyToolTip(Lorg/eclipse/swt/internal/win32/NMHDR;JJ)Lorg/eclipse/swt/internal/win32/LRESULT; (Table.java:7157)
at org.eclipse.swt.widgets.Table.wmNotify(Lorg/eclipse/swt/internal/win32/NMHDR;JJ)Lorg/eclipse/swt/internal/win32/LRESULT; (Table.java:6497)
at org.eclipse.swt.widgets.Control.WM_NOTIFY(JJ)Lorg/eclipse/swt/internal/win32/LRESULT; (Control.java:5381)
at org.eclipse.swt.widgets.Control.windowProc(JIJJ)J (Control.java:4815)
at org.eclipse.swt.widgets.Table.windowProc(JIJJ)J (Table.java:5807)
at org.eclipse.swt.widgets.Display.windowProc(JJJJ)J (Display.java:4913)
at org.eclipse.swt.internal.win32.OS.DispatchMessage(Lorg/eclipse/swt/internal/win32/MSG;)J (Native Method)
at org.eclipse.swt.widgets.Display.readAndDispatch()Z (Display.java:3610)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run()V (PartRenderingEngine.java:1157)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Lorg/eclipse/core/databinding/observable/Realm;Ljava/lang/Runnable;)V (Realm.java:338)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(Lorg/eclipse/e4/ui/model/application/MApplicationElement;Lorg/eclipse/e4/core/contexts/IEclipseContext;)Ljava/lang/Object; (PartRenderingEngine.java:1046)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(Lorg/eclipse/e4/ui/model/application/MApplicationElement;)V (E4Workbench.java:155)
...
@SyntevoAlex try maximizing the window, @jukzi's screenshot also has it occupying one of the displays entirely according to the window icon. Yours has just a few pixels left, which might make all the difference 😄
Unfortunately I don't have the time to investigate.
Looks like a Microsoft Windows OS bug:
@jukzi is there an official bug report that you know of for that? I couldn't find any.