experimental rescaling option leads to application blocked

[Bananeweizen]

All our developers run 2024-12. We have centrally enabled the experimental "rescaling at runtime" option, see https://eclipse.dev/eclipse/news/4.34/platform.html#rescale-on-runtime-preference or #2461. The rescaling works great.

However, for a small number of developers enabling that option lead to their application not reacting anymore in arbitrary situations. We checked stack traces of one affected developer and found that the thread using the MS Edge browser blocks, whenever a tooltip shall be displayed. This blocking does not happen for all developers, rather for a small percentage only. Still, we had to disable the rescaling option for all of them.

I'd like to request making the use of MS Edge for tooltips an independent option, if possible.

[HeikoKlare]

Thank you for reporting this, @Bananeweizen! Great to hear that you have already tested the "rescaling at runtime" feature with your developers and that, overall, you seem to be satisfied. Looking forward to your further feedback, once the feature becomes usable for you again after the reported bug is fixed.

The issue you report may be a more severe one, as there is a chance that it is not limited to the "rescaling at runtime" option being enabled, but that it may be related to Edge in general. Since we made Edge the default browser on Windows for the complete IDE during the current development cycle (eclipse-platform/eclipse.platform.swt#1637), it may affect every application now, no matter whether the "rescaling at runtime" feature is enabled or not.

I have also faced freezes caused by Edge (with "rescaling at runtime" enabled") just recently (and very sporadically), but did not dig into it so far. I found the main thread being stuck in processing OS events. My impression is that there is something going wrong with the asynchronous event processing performed by Edge leading to a kind of halt in the ordinary OS event processing.

Do you have any further insights why some developers may be affected while others are not? E.g., do they use different OS / Edge/WebView2 versions? Do they use the same "configuration" of the IDE, i.e., same installed plug-ins, same used perspectives etc.?

We will definitely have a look into this issue very soon because of the urgency arising from the points mentioned above. I placed it with top priority in our backlog.

I'd like to request making the use of MS Edge for tooltips an independent option, if possible.

That should be possible and in case we do not find the reasons and a fix for the freezes that might be something we should consider. The reason why we did not do that (but instead put effort into making Edge usable as default browser) is that Internet Explorer does not work that well with (monitor-specific) HiDPI settings and we did not want to invest into Internet Explorer anymore. So the result of using monitor-specific scaling without Edge would be that all browser instances (Javadoc, Tooltips, Help etc.) will not properly adapt to the current monitor's scaling.

[HeikoKlare]

Might be that this kind of issue was not detected by tests so far, as the timeout for browser instantiation has been increased significantly:

• Increase max time to create Edge browser in tests. eclipse.platform.swt#1677

There is a pending PR reducing the timeout again, which sporadically fails because of a timeout (e.g., browser not being instantiated after 60 seconds):

• Browser tests: reduce timeout for instantiation to reasonable value eclipse.platform.swt#1706

Those timeouts could be results of the same root cause than the issue reported here.

[Bananeweizen]

@HeikoKlare The thread dump that we had taken also didn't immediately look suspicious for the main thread. AFAIR the waiting for edge happened in another thread, but I'm not sure anymore. Maybe @frankbenoit can provide a thread dump, he initially reported the issue.

[HeikoKlare]

Additional note: we sometimes (very seldom) see SWT builds that do not terminate because an Edge test completely blocks the execution. For example, in https://github.com/eclipse-platform/eclipse.platform.swt/actions/runs/12894713433/job/35953992055?pr=1744 there is this trace:

[2025-01-21 19:59:26 +0000] org.eclipse.swt.tests.junit.Test_org_eclipse_swt_browser_Browser.test_getText_script[browser flags: 0]() ran for more than 60 seconds
totalMemory:             146800640
freeMemory (before GC):   77967384
freeMemory (after GC):    58264344
"main" prio=5 Id=1 TIMED_WAITING
	at java.base@21.0.5/java.lang.Thread.sleep0(Native Method)
	at java.base@21.0.5/java.lang.Thread.sleep(Thread.java:509)
	at app//org.eclipse.swt.tests.junit.Test_org_eclipse_swt_browser_Browser.afterDispose(Test_org_eclipse_swt_browser_Browser.java:257)
	at app//org.eclipse.swt.tests.junit.Test_org_eclipse_swt_widgets_Widget$1.dispose(Test_org_eclipse_swt_widgets_Widget.java:73)
	at app//org.eclipse.test.Screenshots$ScreenshotOnFailure.finished(Screenshots.java:47)
	at app//org.junit.rules.TestWatcher.finishedQuietly(TestWatcher.java:122)
	at app//org.junit.rules.TestWatcher.access$400(TestWatcher.java:52)
	at app//org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:70)
	...
"Reference Handler" daemon prio=10 Id=9 RUNNABLE
	at java.base@21.0.5/java.lang.ref.Reference.waitForReferencePendingList(Native Method)
	at java.base@21.0.5/java.lang.ref.Reference.processPendingReferences(Reference.java:246)
	at java.base@21.0.5/java.lang.ref.Reference$ReferenceHandler.run(Reference.java:208)
"Finalizer" daemon prio=8 Id=10 WAITING on java.lang.ref.NativeReferenceQueue$Lock@72cd3b7f
	at java.base@21.0.5/java.lang.Object.wait0(Native Method)
	-  waiting on java.lang.ref.NativeReferenceQueue$Lock@72cd3b7f
	at java.base@21.0.5/java.lang.Object.wait(Object.java:366)
	at java.base@21.0.5/java.lang.Object.wait(Object.java:339)
	at java.base@21.0.5/java.lang.ref.NativeReferenceQueue.await(NativeReferenceQueue.java:48)
	at java.base@21.0.5/java.lang.ref.ReferenceQueue.remove0(ReferenceQueue.java:158)
	at java.base@21.0.5/java.lang.ref.NativeReferenceQueue.remove(NativeReferenceQueue.java:89)
	at java.base@21.0.5/java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:173)
"Signal Dispatcher" daemon prio=9 Id=11 RUNNABLE
"Attach Listener" daemon prio=5 Id=12 RUNNABLE
"Notification Thread" daemon prio=9 Id=18 RUNNABLE
"Common-Cleaner" daemon prio=8 Id=19 TIMED_WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@6c192db1
	at java.base@21.0.5/jdk.internal.misc.Unsafe.park(Native Method)
	-  waiting on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@6c192db1
	at java.base@21.0.5/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:269)
	at java.base@21.0.5/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1852)
	at java.base@21.0.5/java.lang.ref.ReferenceQueue.await(ReferenceQueue.java:71)
	at java.base@21.0.5/java.lang.ref.ReferenceQueue.remove0(ReferenceQueue.java:143)
	at java.base@21.0.5/java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:218)
	at java.base@21.0.5/jdk.internal.ref.CleanerImpl.run(CleanerImpl.java:140)
	at java.base@21.0.5/java.lang.Thread.runWith(Thread.java:1596)
	...
"surefire-forkedjvm-stream-flusher" daemon prio=5 Id=23 TIMED_WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@40a76fc2
	at java.base@21.0.5/jdk.internal.misc.Unsafe.park(Native Method)
	-  waiting on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@40a76fc2
	at java.base@21.0.5/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:269)
	at java.base@21.0.5/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1763)
	at java.base@21.0.5/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1182)
	at java.base@21.0.5/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:899)
	at java.base@21.0.5/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1070)
	at java.base@21.0.5/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
	at java.base@21.0.5/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
	...
"surefire-forkedjvm-command-thread" daemon prio=5 Id=25 RUNNABLE (in native)
	at java.base@21.0.5/java.io.FileInputStream.readBytes(Native Method)
	at java.base@21.0.5/java.io.FileInputStream.read(FileInputStream.java:287)
	at java.base@21.0.5/java.io.BufferedInputStream.read1(BufferedInputStream.java:345)
	at java.base@21.0.5/java.io.BufferedInputStream.implRead(BufferedInputStream.java:420)
	at java.base@21.0.5/java.io.BufferedInputStream.read(BufferedInputStream.java:399)
	at java.base@21.0.5/java.io.BufferedInputStream.fill(BufferedInputStream.java:291)
	at java.base@21.0.5/java.io.BufferedInputStream.read1(BufferedInputStream.java:347)
	at java.base@21.0.5/java.io.BufferedInputStream.implRead(BufferedInputStream.java:420)
	...
	Number of locked synchronizers = 2
	- java.util.concurrent.locks.ReentrantLock$NonfairSync@4c9cbd82
	- java.util.concurrent.locks.ReentrantLock$NonfairSync@579161ad
"ForkJoinPool.commonPool-worker-3" daemon prio=5 Id=35 TIMED_WAITING on java.util.concurrent.ForkJoinPool@72c0ba4b
	at java.base@21.0.5/jdk.internal.misc.Unsafe.park(Native Method)
	-  waiting on java.util.concurrent.ForkJoinPool@72c0ba4b
	at java.base@21.0.5/java.util.concurrent.locks.LockSupport.parkUntil(LockSupport.java:449)
	at java.base@21.0.5/java.util.concurrent.ForkJoinPool.awaitWork(ForkJoinPool.java:1891)
	at java.base@21.0.5/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1809)
	at java.base@21.0.5/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:188)
"Timer-0" daemon prio=5 Id=36 RUNNABLE
	at java.management@21.0.5/sun.management.ThreadImpl.dumpThreads0(Native Method)
	at java.management@21.0.5/sun.management.ThreadImpl.dumpAllThreads(ThreadImpl.java:518)
	at app//org.eclipse.test.TracingSuite$DumpTask.dumpStackTraces(TracingSuite.java:249)
	at app//org.eclipse.test.TracingSuite$DumpTask.run(TracingSuite.java:203)
	at java.base@21.0.5/java.util.TimerThread.mainLoop(Timer.java:566)
	at java.base@21.0.5/java.util.TimerThread.run(Timer.java:516)
AWT screenshot saved to: C:\Users\RUNNER~1\AppData\Local\Temp\org.eclipse.test.TracingSuite.0.png

[HeikoKlare]

Meanwhile, we have identified potential causes for Edge freezing the application by blocking the UI thread. We are fixing the underlying issues as far as possible (and as far as we can identify them with the current information we have) but we also focus on ensuring that we rather fail some operation than blocking the UI thread.

We now also have a concrete freeze scenario documented that might be related to your issue: eclipse-platform/eclipse.platform.swt#1771

To better understand whether we will cover the issue that you experienced, it would be great if you still have a thread dump, a sample or something else that you can share, @frankbenoit @Bananeweizen.

[HeikoKlare]

@Bananeweizen Here are some updates on Edge browser issues and monitor-specific scaling.

After the 2024-12 release, we have worked in several improvements for Edge. This also includes the systematic prevention of UI thread blocks by either avoiding the cause or introducing timeouts at all places that might block the UI (to work around potential root causes that we may currently not be aware of). In consequence, the worst that should happen now is that a browser widget is not initialized correctly, but the UI should not block:

• WebViewWrapperFuture handling on job termination timeout eclipse.platform.swt#1752
• [Win32] Avoid blocking operations on Edge due to OS message processing eclipse.platform.swt#1776
• [Win32] Make Edge only process relevant OS messages #1789 eclipse.platform.swt#1797

We are looking forward to getting further feedback from you, be it that your problems are resolved but also if you experience that sometimes browers are not initialized correctly.
Note that with the upcoming Eclipse 2025-03 release, Edge becomes the default browser even without monitor-specific scaling:
https://eclipse.dev/eclipse/news/4.35/platform.html#edgeBrowserDefault
In the unlikely case that you still have blocking issues with Edge, you can now explicitly switch back to internet explorer via VM argument (see the news entry). That will also apply when you are using monitor-specific scaling (i.e., this would allow you to use monitor-specific scaling with internet explorer).

We have also further enhanced the monitor-specific scaling for the 2025-03 release. So we are really looking forward to having you activate that feature for your developers again and receiving further feedback: https://eclipse.dev/eclipse/news/4.35/platform.html#rescaleOnRuntimePreference

With the above mentioned, I consider this issue as resolved for now. In case further issues come up with 2025-03, feel free to create according tickets (or reopen this one).