Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Edge/WebView2 as the default browser on Windows #1466 #1637

Merged

Conversation

HeikoKlare
Copy link
Contributor

@HeikoKlare HeikoKlare commented Dec 6, 2024

This change replaces Internet Explorer as the default browser used on Windows with Edge/WebView2.

Internet Explorer is progressively taken out of support while Edge/WebView2 and replace by Edge/WebView2. It provides a more future-proof browser integration capability for SWT on Windows, with better capabilities, performance, and development tooling support.

This change consists of the following:

  • Introduce SWT flag SWT.IE to be used for Browser to create an Internet Explorer instance
  • Adapt mapping of existing VM argument for default browser to map "ie" to new Internet Explorer flag and use Edge as default
  • Make SWT Browser instantiate Edge on Windows by default, i.e., unless the flag SWT.IE is specified
  • Adapt the SWT ControlExample to represent the SWT.IE flag and properly switch between Edge, Internet Explorer and default
  • Adapt Browser tests to consider to new default configuration

Contributes to #1466
Fixes #840

@HeikoKlare HeikoKlare requested a review from sratz December 6, 2024 11:23
Copy link
Contributor

github-actions bot commented Dec 6, 2024

Test Results

   383 files  ±  0     383 suites  ±0   5m 39s ⏱️ + 1m 4s
 4 286 tests +190   4 272 ✅ +183  14 💤 +7  0 ❌ ±0 
12 150 runs  ±  0  12 065 ✅ ±  0  85 💤 ±0  0 ❌ ±0 

Results for commit 09c8230. ± Comparison against base commit 44dda53.

This pull request skips 4 tests.
org.eclipse.swt.tests.junit.Test_org_eclipse_swt_browser_Browser ‑ test_Constructor_multipleInstantiationsInDifferentThreads[browser flags: 0]
org.eclipse.swt.tests.junit.Test_org_eclipse_swt_browser_Browser ‑ test_TabTraversalOutOfBrowser[browser flags: 0]
org.eclipse.swt.tests.junit.Test_org_eclipse_swt_browser_Browser ‑ test_setUrl_local[browser flags: 0]
org.eclipse.swt.tests.junit.Test_org_eclipse_swt_browser_Browser ‑ test_setUrl_remote[browser flags: 0]

♻️ This comment has been updated with latest results.

@HeikoKlare HeikoKlare force-pushed the issue-1466-edge-default branch 2 times, most recently from c3eb4dc to f6617aa Compare December 6, 2024 15:04
@HeikoKlare HeikoKlare marked this pull request as ready for review December 6, 2024 15:19
@HeikoKlare HeikoKlare requested a review from fedejeanne December 9, 2024 10:40
@HeikoKlare HeikoKlare force-pushed the issue-1466-edge-default branch 2 times, most recently from 1b76c75 to 075d949 Compare December 9, 2024 12:00
@@ -3688,7 +3688,7 @@ public void setRedraw (boolean redraw) {
private boolean embedsWin32Control () {
if (this instanceof Browser) {
// The Edge browser embeds webView2
return (getStyle() & SWT.EDGE) != 0;
return (getStyle() & SWT.IE) == 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that we always have the "EDGE" flag set, I think we should keep this check as it was before

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do not always have the flag set. By default, the style flag will simply be SWT.NONE.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In its current state (075d949) this wouldn't work because SWT.EDGE is set if (current.equalsIgnoreCase ("edge") && "win32".equals (platform)) which means one has to explicitly provide the parameter. Not providing any parameter still sets the style to SWT.NONE

Copy link
Member

@sratz sratz Dec 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, right.

Alternatively, how about this, to keep this an explicit check, not an implicit one?

	if (this instanceof Browser browser) {
		// The Edge browser embeds webView2
		return "edge".equals(browser.getBrowserType());
	}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. I've adapted the code with c0466d7.

@HeikoKlare HeikoKlare force-pushed the issue-1466-edge-default branch 2 times, most recently from 428a039 to c0466d7 Compare December 9, 2024 15:03
@sratz
Copy link
Member

sratz commented Dec 9, 2024

Changes look good.

But what's that weird

"The field org.eclipse.swt.SWT.IE has been added to a class"

API error about?

@HeikoKlare
Copy link
Contributor Author

But what's that weird

"The field org.eclipse.swt.SWT.IE has been added to a class"

API error about?

Where do you see that error? The added field is an (accepted) API change for which I added an according compatibility filter.

@sratz
Copy link
Member

sratz commented Dec 9, 2024

But what's that weird
"The field org.eclipse.swt.SWT.IE has been added to a class"
API error about?

Where do you see that error? The added field is an (accepted) API change for which I added an according compatibility filter.

I wanted to see what the filters were for and temporarily removed it and was wondering why that's the only occurrence of SWT in the API filters / why this was not needed before.

@HeikoKlare
Copy link
Contributor Author

I wanted to see what the filters were for and temporarily removed it

The filter is for introduced breaking API change. Adding a public field to a class is actually a breaking change (but one that you can usually accept as the chance of any issue because of that are unlikely).

and was wondering why that's the only occurrence of SWT in the API filters / why this was not needed before.

I think there is no other filter for the SWT class because for every other breaking API change, for which a filter was added, that filter was removed in the subsequent release cycle, because the API then became compatible with the baseline version (the previous release) again.

@sratz
Copy link
Member

sratz commented Dec 10, 2024

I think there is no other filter for the SWT class because for every other breaking API change, for which a filter was added, that filter was removed in the subsequent release cycle, because the API then became compatible with the baseline version (the previous release) again.

Makes sense, thanks for the clarification!

@HeikoKlare HeikoKlare added the noteworthy N&N entry label Dec 10, 2024
@HeikoKlare HeikoKlare added this to the 4.35 M1 milestone Dec 10, 2024
…1466

- Introduce SWT flag SWT.IE to be used for Browser to create an Internet
  Explorer instance
- Adapt mapping of existing VM argument for default browser to map "ie"
  to new Internet Explorer flag and use Edge as default
- Make SWT Browser instantiate Edge on Windows by default, i.e., unless
  the flag SWT.IE is specified
- Adapt the SWT ControlExample to represent the SWT.IE flag and properly
  switch between Edge, Internet Explorer and default
- Adapt Browser tests to consider to new default configuration

Contributes to
eclipse-platform#1466
@HeikoKlare HeikoKlare force-pushed the issue-1466-edge-default branch from c0466d7 to 09c8230 Compare December 10, 2024 11:54
@HeikoKlare HeikoKlare merged commit 43b6820 into eclipse-platform:master Dec 10, 2024
7 of 11 checks passed
@HeikoKlare HeikoKlare deleted the issue-1466-edge-default branch December 10, 2024 12:15
@akurtakov
Copy link
Member

This seem to have missed a version bump as can be seen at https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/master/828/console and even fails eclipse-platform/eclipse.platform.releng.aggregator#2649 .
I really ask everyone to be far more careful in expecting and enhancing releng scripts to be more strict where they aren't as keeping things building becomes a full time job without any possibility to look into anything else for me.

akurtakov added a commit to akurtakov/eclipse.platform.swt that referenced this pull request Dec 11, 2024
akurtakov added a commit that referenced this pull request Dec 11, 2024
Fixes broken stream after
#1637
@fedejeanne
Copy link
Contributor

@akurtakov I don't see the errors that you mention in the logs, only the 3 know test failures: #1564.

And I don't see the relation to eclipse-platform/eclipse.platform.releng.aggregator#2649 or eclipse-equinox/equinox#716 in this PR either.

Could you please be more specific so next time we know what to look for?

@HeikoKlare
Copy link
Contributor Author

HeikoKlare commented Dec 11, 2024

We missed these messages:

Caused by: org.eclipse.tycho.core.exceptions.VersionBumpRequiredException: Only qualifier changed for (org.eclipse.swt.examples/3.108.600.v20241210-1215). Expected to have bigger x.y.z than what is available in baseline (3.108.600.v20241014-1802)

Sorry for that and thank you for bumping the version, @akurtakov. Don't know why/how I missed that...
Seems to be quite hard to track around the failures we currently have in SWT builds. We should definitely find a solution for the Linux test failures, because they make so many checks fail unnecessarily. This is not meant to ask anyone specific to look at those tests, but honestly, if no one really cares about the issues those tests reveal, we may also think about simply deactivating those tests on Linux.

I see that the Windows tests are also failing today because of some unsuccessful cleanup related to this PR (as it is related to Edge being used), see https://download.eclipse.org/eclipse/downloads/drops4/I20241211-0310/testresults/consolelogs/ep435I-unit-win32-x86_64-java17_win32.win32.x86_64_17_consolelog.txt:

C:\Users\genie.releng\workspace\AutomatedTests\ep435I-unit-win32-x86_64-java17\workarea\I20241211-0310\eclipse-testing\test.xml:132: Unable to delete file C:\Users\genie.releng\workspace\AutomatedTests\ep435I-unit-win32-x86_64-java17\workarea\I20241211-0310\eclipse-testing\test-eclipse\eclipse\update_configurator_folder.metadata.plugins\org.eclipse.swt\EBWebView\lockfile

Do you have a look at them, @fedejeanne @amartya4256?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
noteworthy N&N entry
Projects
None yet
Development

Successfully merging this pull request may close these issues.

The internal browser is outdated
4 participants