Process KeyBinding Command Asyncly for Browser

[amartya4256]

This PR adapts how KeyBindingDispatcher processed Key events in case of Browser. If the trigger of the event is a browser, it processes the command asynchronously to avoid any possible deadlocks.

Contributes to #3104

Problem Explained
KeyBindings are registered globally with the Display. Inside the browser when a key combination is pressed which might open up another browser and use it synchronously, the browser needs to wait for the callback to finish and since it is not possible in case of Edge browser, it goes in a deadlock.

To achieve this, we must process the commands asynchronously. However, we need to tell the browser if the event eats the key event (sets event.doit = false) as the key is handled by SWT and not the browser natively. Hence, we need to proactively check if a command for the key event is going to be executed. If yes, it eats the key otherwise the browser can execute native action on the key event.

Fixes eclipse-platform/eclipse.platform.swt#1801

[github-actions]

Test Results

 3 024 files  + 9   3 024 suites  +9   2h 19m 40s ⏱️ + 15m 27s
 8 234 tests ± 0   7 986 ✅ + 1  248 💤 ±0  0 ❌  - 1 
23 526 runs  +26  22 735 ✅ +24  791 💤 +3  0 ❌  - 1 

Results for commit 68cafdb. ± Comparison against base commit e6d3cbf.

♻️ This comment has been updated with latest results.

[HeikoKlare]

At a first glance, this looks like a reasonable workaround according to the proposal in #3104 (comment).

One concern regarding behavior is the clearance of the keyAssistDialog state. And note that a bunch of related tests is failing now.
My other current comments are rather regarding style.

[HeikoKlare]

Why is the command.isEnabled() check added here?

[amartya4256]

if the command is not enabled, the code simply registers an execption and proceeds. Later this leads to commandHandled being set to false. Note that this needed to decide if the current handler eats the key. If the eatKey is false then the next handler in the notifyListener handles this event. e.g. CTRL + A can have multiple handler and if the first handler is not enabled and the second one should perform the command. The first one should set the commandHandled to false and not eatKey so that it would be propagated to the second handler. Since we can check this proactively before handlerService#executeHandler, we leverage this to already check if it can execute. Similar check is also performed inside Command#execute.

[HeikoKlare]

Great, thank you for the detailed explanation!

[HeikoKlare]

The change now looks good to me. It also properly resolves the issue reported in #3104 for me.

@sratz can you please also have a look as you have been involved into the issue and made proposals for how to fit it as well?

[eclipse-platform-bot]

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

bundles/org.eclipse.e4.ui.bindings/META-INF/MANIFEST.MF

Warning

🚧 This PR cannot be modified by maintainers because edits are disabled or it is created from an organization repository. To obtain the required changes apply the git patch manually as an additional commit.

Git patch

From a008cc62c53d9ec82af739c5476cbd258c5bffac Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <platform-bot@eclipse.org>
Date: Mon, 2 Mar 2026 14:46:58 +0000
Subject: [PATCH] Version bump(s) for 4.40 stream


diff --git a/bundles/org.eclipse.e4.ui.bindings/META-INF/MANIFEST.MF b/bundles/org.eclipse.e4.ui.bindings/META-INF/MANIFEST.MF
index 8f5230070a..5129a6e9e6 100644
--- a/bundles/org.eclipse.e4.ui.bindings/META-INF/MANIFEST.MF
+++ b/bundles/org.eclipse.e4.ui.bindings/META-INF/MANIFEST.MF
@@ -1,7 +1,7 @@
 Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-SymbolicName: org.eclipse.e4.ui.bindings;singleton:=true
-Bundle-Version: 0.15.0.qualifier
+Bundle-Version: 0.15.100.qualifier
 Bundle-Name: %pluginName
 Bundle-Vendor: %providerName
 Bundle-Localization: plugin
-- 
2.53.0

Further information are available in Common Build Issues - Missing version increments.

[HeikoKlare]

Since we are at the very beginning of a new development cycle, it would be a good point in time to merge a change like this. @sratz could you please have a look at this fix as well as it's Edge-related?