experimental rescaling option leads to application blocked #2734
Comments
|
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.
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. |
|
Might be that this kind of issue was not detected by tests so far, as the timeout for browser instantiation has been increased significantly: 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): Those timeouts could be results of the same root cause than the issue reported here. |
|
@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. |
|
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: |
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.
The text was updated successfully, but these errors were encountered: