Edge: Disable internal status bar on the bottom left when hovering link and send out StatusTextEvents instead (like other SWT browser impls)

[sratz]

Edge - by default - shows a status bar when hovering a link:

All the other browser implementations (WebKit, IE) do not.

For an embedded use-case in RCP applications showing such a status bar is typically not desired.

The internal WebView2 API is already there: org.eclipse.swt.internal.ole.win32.ICoreWebView2Settings.put_IsStatusBarEnabled(boolean), but

• it is not call inside the Edge implementation to switch it off by default
• there is no common Browser API to toggle it

I see two options:

1. Disable it by default in Edge to align with all the other browser implementations.
2. Add the possibility to disable it. @akurtakov suggested to use Widget#setData(String, String), similar to https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=2349244f390a9927eab593ddc499b71cb3f0a70b, to avoid having to add actual new Java API:

Option 1 would be trivial.

Option 2 not so hard either:

diff --git a/bundles/org.eclipse.swt/Eclipse SWT Browser/win32/org/eclipse/swt/browser/Edge.java b/bundles/org.eclipse.swt/Eclipse SWT Browser/win32/org/eclipse/swt/browser/Edge.java
index add41906b7..fe9d409edf 100644
--- a/bundles/org.eclipse.swt/Eclipse SWT Browser/win32/org/eclipse/swt/browser/Edge.java
+++ b/bundles/org.eclipse.swt/Eclipse SWT Browser/win32/org/eclipse/swt/browser/Edge.java
@@ -36,6 +36,7 @@ class Edge extends WebBrowser {

        // Display.getData() keys
        static final String APPLOCAL_DIR_KEY = "org.eclipse.swt.internal.win32.appLocalDir";
+       static final String KEY_EDGE_STATUS_BAR_ENABLED = "org.eclipse.swt.internal.win32.edge.statusBarEnabled";

        // System.getProperty() keys
        static final String BROWSER_DIR_PROP = "org.eclipse.swt.browser.EdgeDir";
@@ -633,6 +634,14 @@ int handleNavigationStarting(long pView, long pArgs, boolean top) {
                navigations.put(pNavId[0], event);
                jsEnabled = jsEnabledOnNextPage;
                settings.put_IsScriptEnabled(jsEnabled);
+
+               Object statusBarEnabled = browser.getData(KEY_EDGE_STATUS_BAR_ENABLED);
+               if (statusBarEnabled instanceof String enabled) {
+                       settings.put_IsStatusBarEnabled(Boolean.parseBoolean(enabled));
+               } else {
+                       settings.put_IsStatusBarEnabled(true); // default
+               }
+
                // Register browser functions in the new document.
                if (!functions.isEmpty()) {
                        StringBuilder sb = new StringBuilder();

What do you think?

[HeikoKlare]

Both options sound good to me. I would be in favor of option 2, as it might be good to still have the chance to enable the bar. Two thoughts on that:

• Maybe the feature should be opt-in, i.e., disabled-by-default to be consistent with the other browsers in terms of defaults.
• Is there already a documentation of such (OS-specific) customizations? Would be great to have some central place documenting "non-API" (potentially OS-specific) configuration options (via setData) for widgets.

[sratz]

Both options sound good to me. I would be in favor of option 2, as it might be good to still have the chance to enable the bar. Two thoughts on that:

• Maybe the feature should be opt-in, i.e., disabled-by-default to be consistent with the other browsers in terms of defaults.

Good idea!

• Is there already a documentation of such (OS-specific) customizations? Would be great to have some central place documenting "non-API" (potentially OS-specific) configuration options (via setData) for widgets.

I was wondering the same and also whether the naming scheme with internal.win32 segments makes sense here. After all, this is not an internal API but to be set by the user.

[laeubi]

I was wondering the same and also whether the naming scheme with internal.win32 segments makes sense here. After all, this is not an internal API but to be set by the user.

I think this must be something public available on all OSes otherwise it is to cumbersome to use (e.g. I can't reference it but need to copy the string constant or even need platform dependent compile and so on).

The usual pattern here is to mention in the documentation that it is a only a hint and not supported on all platforms.

That way one can express the intend to enable/disable a feature in a platform independent way.

[sratz]

My proposal for now is this:

If https://learn.microsoft.com/en-us/microsoft-edge/webview2/reference/win32/icorewebview2_12 API (handling of status bar) is available:

• we disable the internal status bar inside the browser to align Edge with all the other SWT Browser implementations.
• we implement StatusBarTextChanged handler and properly send out StatusTextEvents like the other Browser implementations

We do not add new API for now to enable the internal status bar. Maybe we can do so in the future and then also check whether this is possible for Safari / WebKit as well.

I'll provide a PR.

Any objections?

[HeikoKlare]

Fully agree with the proposed change as well aswith the proposal to extend API for enabling internal status bar only on explicit demand.