[Edge] Eclipse freezes when opening more than 2 png files in internal web browser via Ctrl+Shift+R

[arunjose696]

Let's make sure issue is not already fixed in latest builds first.

• I verified I can reproduce this issue against latest Integration Build of Eclipse SDK

Steps to reproduce

From a fresh installation and clean workspace:

Setup eclipse and all the eclipse platform related github repositories using oomph https://www.eclipse.org/setups/installer/?url=https://raw.githubusercontent.com/eclipse-platform/eclipse.platform.releng.aggregator/master/oomph/PlatformSDKConfiguration.setup&show=true

Open 2 or more *.png files(Images) with ctrl+shift+r. This causes eclipse to hang.

I expected: No hangs

But got: Eclipse hangs

Here is jstack of eclipse process id

Jstack eclipse.txt

Tested under this environment:

• OS & version: Windows 11
• Eclipse IDE/Platform version (as shown in Help > About): Version: 2025-09 (4.37)
  Build id: I20250710-1800

Community

• I understand reporting an issue to this OSS project does not mandate anyone to fix it. Other contributors may consider the issue, or not, at their own convenience. The most efficient way to get it fixed is that I fix it myself and contribute it back as a good quality patch to the project.

[sratz]

Important excerpt of the stack:

"main" #1 [34668] prio=6 os_prio=0 cpu=77593.75ms elapsed=1087.31s tid=0x0000021089970e30 nid=34668 runnable  [0x0000003865dda000]
   java.lang.Thread.State: RUNNABLE
        at org.eclipse.swt.internal.win32.OS.PeekMessage(Native Method)
        at org.eclipse.swt.browser.Edge.processOSMessagesUntil(Edge.java:530)
        at org.eclipse.swt.browser.Edge$WebViewProvider.getWebViewWrapper(Edge.java:435)
        at org.eclipse.swt.browser.Edge$WebViewProvider.getWebViewWrapper(Edge.java:424)
        at org.eclipse.swt.browser.Edge$WebViewProvider.getWebView(Edge.java:443)
        at org.eclipse.swt.browser.Edge.isBackEnabled(Edge.java:1528)
        at org.eclipse.swt.browser.Browser.isBackEnabled(Browser.java:875)
        at org.eclipse.ui.internal.browser.BrowserViewer.isBackEnabled(BrowserViewer.java:604)
        at org.eclipse.ui.internal.browser.BrowserViewer.updateBackNextBusy(BrowserViewer.java:318)
        at org.eclipse.ui.internal.browser.BrowserViewer.<init>(BrowserViewer.java:264)
        at org.eclipse.ui.internal.browser.WebBrowserEditor.createPartControl(WebBrowserEditor.java:78)
        at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.createPartControl(CompatibilityPart.java:160)
        ...
        at org.eclipse.ui.internal.ide.handlers.OpenResourceHandler.run(OpenResourceHandler.java:182)
        at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent(KeyBindingDispatcher.java:662)
        ...
        at org.eclipse.swt.browser.WebBrowser.sendKeyEvent(WebBrowser.java:717)
        at org.eclipse.swt.browser.Edge.handleAcceleratorKeyPressed(Edge.java:1495)
        at org.eclipse.swt.browser.Edge$$Lambda/0x00000210b0cc9e28.Invoke(Unknown Source)
        at org.eclipse.swt.browser.Edge$HandleCoreWebView2SwtCallback.Invoke(Edge.java:250)
        at org.eclipse.swt.internal.win32.OS.PeekMessage(Native Method)
        at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3741)

The problem is that Ctrl+Shift+R is pressed inside the first internal web browser and then we end up in a deadlock due to already being inside OS.PeekMessage.

[HeikoKlare]

Wouldn't it be better (= less dangerous) to asynchronously process such key-pressed events in general? That would avoid that the listeners to such events run into any unsupported loops (such as calling OS.PeekMessage again, as we see here). But not sure if that's even possible given that the callback modifies the state of the event arguments based on what the listeners to the event did.

[sratz]

Wouldn't it be better (= less dangerous) to asynchronously process such key-pressed events in general? That would avoid that the listeners to such events run into any unsupported loops (such as calling OS.PeekMessage again, as we see here). But not sure if that's even possible given that the callback modifies the state of the event arguments based on what the listeners to the event did.

It would be much safer, yes, but sadly, listeners are allowed to suppress the key event.

So I am not sure how we could even attempt to fix this centrally. Some thoughts:

1. I wonder why something like this does not happen in e.g. Safari/WebKit?
2. I don't see how we could decouple / asyncExec inside SWT without violating the contract that listeners can suppress the key event.
3. Maybe in org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent we could introduce a workaround? Here we could maybe call executeCommand() asynchronously, if the source of the event is a Browser.

[HeikoKlare]

1. I wonder why something like this does not happen in e.g. Safari/WebKit?

I think the difference is that while both Webkit and Edge do all interactions asynchronously, Webkit is still initialized in a synchronous way while Edge even does that asynchronously. That's why we have that WebViewWrapper and need to do the event processing inside Edge, as it might happen that you execute some operation on an Edge instance which is not fully initialized yet. That's something that cannot happen for Webkit. Still it might be worth to take another look into. One could execute the same scenario and debug what Webkit does (in particular, what happens when the key event is processed).

3. Maybe in org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent we could introduce a workaround? Here we could maybe call executeCommand() asynchronously, if the source of the event is a Browser.

Yes, it seems like some consumer-side workaround is necessary. I am just not sure if that's a good place considering the risk of unintended side effects, in particular since I am not sure how often this control flow happens in practice and thus how good such a change will be tested.

Since we only know about this very specific issue yet, maybe we could do the fix even more locally: as the stack trace shows, it's about some additional initialization of the browser control inside the BrowserViewer and taking a look at the code, I only see this specific line of code that may lead to a deadlock:

eclipse.platform.ui/bundles/org.eclipse.ui.browser/src/org/eclipse/ui/internal/browser/BrowserViewer.java

Lines 263 to 264 in 6c10cbf

	if (showToolbar)
	updateBackNextBusy();

So maybe it would suffice to just do this initialization asynchronously?