Community
Participate
Working Groups
Any chance Edge can be the default browser to embed on Windows for the Browser component, when available? IE is becoming a bit of a problem when using various JavaScript libraries. For example, https://github.com/thegreystone/jmc-flame-view doesn't currently work on Windows, due to IE being used. Rendering it in an external Edge browser works, as pointed out by Nenad Bogojevic in one of the issues.
Introducing this feature is interesting considering that edge is migrating to Chromium.
It may be interesting to integrate the new webview2 control instead of the old one. This would make the ticket 405031 useless and saving space on the disk. https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2/gettingstarted
Chromium-based Edge (WebView2) is generally available for Win7 and later. I'll work on SWT integration.
(In reply to Marco Monacelli from comment #2) > It may be interesting to integrate the new webview2 control instead of the > old one. > > This would make the ticket 405031 useless and saving space on the disk. > https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2/ > gettingstarted this will make ticket 405031 NOT useless.. We need in Eclipse a standard browser that is the same every where In our product we don't only have problems with the embedded IE but also Safari on the Mac gives us headaches We need an "Electron" for Eclipse, the same thing where ever we deploy on (windows,osx,linux)
Nikita, did you have any luck with the SWT-integration of WebView2?
(In reply to Marcus Hirt from comment #5) > Nikita, did you have any luck with the SWT-integration of WebView2? I have the initial port done, but there are many issues. I'll publish the WIP patch this week.
Just adding this as an update for folks reading this bug: * The Flame View is in JMC proper from JMC 7.1, i.e. it is no longer developed in my private repo. * The Flame View is not in the JMC perspective by default, since it doesn't work on Windows. * The JMC project is contemplating a horrid workaround, but we haven't stomached actually integrating it quite yet: https://github.com/openjdk/jmc/pull/41 * The Flame View is actively worked on, and is starting to look pretty good in JMC 8. :)
I just talked to Mario Torre. He said a few Red Hat people may be able to help out with this.
i wouldn't hold my breath for that long.. its seems that the core swt/eclipse team doesn't really see the urgent need for this to move on and drop IE as many users of the eclipse platform do. If it is this bug as a solution or what i prefer a bit more: https://bugs.eclipse.org/bugs/show_bug.cgi?id=549585 (because then it is like electron, you know what you get on any platform, we also have problems with OSX and the embedded safari) It seems that nobody is in a big hurry We already have supported the above implementation with a contribution (as in money). But also that one is already in a standstill for many months. The problem with this case is a bit that it will take quite some time (years even) before most or all window users have and embedded chromium based Edge installed.. So then i guess we need to fall back on IE? So you don't have any idea what the user actual gets, and it is just a gamble if Flame View works?
(In reply to Johan Compagner from comment #9) > The problem with this case is a bit that it will take quite some time (years > even) before most or all window users have and embedded chromium based Edge > installed.. So then i guess we need to fall back on IE? So you don't have > any idea what the user actual gets, and it is just a gamble if Flame View > works? 1) MS is using Windows Update to replace legacy Edge with Chromium Edge, see here https://blogs.windows.com/msedgedev/2020/01/15/upgrading-new-microsoft-edge-79-chromium/. I think we're looking at months, not years. 2) You can ship Chromium Edge with your product and not depend on the system installation (MS calls it BYO = bring your own). IIRC it's as simple as copying the installed Edge directory and feeding the path to the API. The size is huge though, ~100 MB packed. 3) You can always ask your users to install Chromium Edge. Not ideal, but probably better than falling back to IE.
there are loads and loads of people on older versions of Windows (not the latest 10, Windows 8, Windows 7) I can't believe MS wil push it to that
(In reply to Johan Compagner from comment #11) > there are loads and loads of people on older versions of Windows (not the > latest 10, Windows 8, Windows 7) > I can't believe MS wil push it to that Then you're left with options 2 and 3. Chromium Edge works on Win7+.
I am willing to bet that most JMC users on Windows will be on Windows 10. If the alternative to having the Flame View working for an overwhelming percentage of the Windows users is having the Flame View working for no Windows users at all, I'll pick the alternative making it working for almost all users. I'd happily add a release note saying it will not work for pre-Windows 7. When Windows stopped shipping IE as the default browser, I think it would have made sense to switch to Edge as the default embedded browser, instead of relying on old deprecated technology. For practical reasons, given that WebView2 just came around, I can see why this didn't happen.
Hi Nikita! Just wanted to check if this is still something you are interesting in pursuing. I could try to see if there are any people I know with relevant experience who can consider helping out.
If it could be useful. I tried to create a Composite starting from the code of these two projects: https://github.com/zserge/webview/ https://github.com/shannah/webviewjar setText work execute work But not BrowserFunction work. The zserge framework have bind function but not work on my test.
Excellent. Nikita, did you ever get BrowserFunction to work in your implementation?
He, I solved the BrowserFunction issue today. In the next few days I will refactoring the code and publish the work on github. WebView2 APIs are still a bit unstable but I think they are ready soon. If you want you can use my work.
Hi Marco! This is great news! Certainly for JDK Mission Control on Windows. :) Hopefully Nikita and you can join forces to get this finalized and into Eclipse/SWT! (IMHO, after this is in, SWT should be using Edge by default, if available.)
Hello, I have publicate first implementation here: https://github.com/marcom1981/SwtEdgeBrowser Much work is still needed. Currently if Edge Canary is not installed the software crashes. But I think it's a start to show you the progress.
Nice!
Any progress on SWT integration of Edge?
Thanks for contributing initial work!!! Could you post the instruction how to run SwtEdgeBrowser in github. Edge Chromium 83 is released. Once I installed last Edge 83, we don't need to install Edge Canary, is SwtEdgeBrowser program will crash?
I Add this information. Required Edge 84.0.522.39+ Now BETA Channel and SWT 4.7 To Run demo use this class: it.marcom.swtedge.sample.SwtEdgeTest I hope they are sufficient instructions to me it works.
Thanks, Marco. I downloaded Edge 84.0.522.39+ Now BETA Channel and run the program. During runtime, it fails in constructor of NativeEdge if(getWindow(edgePointer)==0) getWindow call in my environment return 0, it throws NativeEdgeException, NativeEdge browser not being initialized. Is there any trick or extra configuration for Edge 84 Beta? I have set my OS default browser to Edge 84 beta BTW, System.load webview.dll and WebView2Loader.dll is successful. I would appreciate if you can shed some light on.
It works for me. the only important thing is to install only the beta version of edge, as the microsft library automatically searches for the most stable version. This does not make the library work. if you have stable and beta installed together the library fails.
Thanks, Macro. After setting beta Edge as default browser, I have to re-launch eclipse, reimport the source code, then it picks Edge browser and your program works.
AFAICS currently we still support only IE on Windows in standard SWT. What are the plans here? Is it planned to support Chromium-based Edge as new standard? Looks like IE will not be supported for long anymore: https://techcommunity.microsoft.com/t5/microsoft-365-blog/microsoft-365-apps-say-farewell-to-internet-explorer-11-and/ba-p/1591666 Quote: Beginning November 30, 2020, the Microsoft Teams web app will no longer support IE 11. Beginning August 17, 2021, the remaining Microsoft 365 apps and services will no longer support IE 11.
(In reply to Marco Monacelli from comment #23) > I Add this information. > Required Edge 84.0.522.39+ Now BETA Channel and SWT 4.7 > To Run demo use this class: it.marcom.swtedge.sample.SwtEdgeTest > > I hope they are sufficient instructions to me it works. Any plans to take this work forward into SWT master ?
the problem is getting bigger if people are starting to use Bootstrap 5: https://getbootstrap.com/docs/5.0/migration/#browser-support-1 they are dropping there IE completely (including 11 which for example Angular still supports)
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/174084
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt.binaries/+/174085
The first version of the Edge support patch is available on Gerrit. It's marked WIP, but there are no major issues, only some missing features. Basic usage and limitations are described in this temporary document: bundles\org.eclipse.swt\EdgeSupportNotes.rst document (part of the patch). Until SWT binaries repo is updated, you'd also need WebView2Loader.dll from either this patch https://git.eclipse.org/r/c/platform/eclipse.platform.swt.binaries/+/174085 or this NuGet package: https://www.nuget.org/packages/Microsoft.Web.WebView2. The biggest disappointment is that stable Edge versions can't be embedded. A separate WebView2 runtime has to be installed (or bundled).
Do you think that will change with future versions, or will this always be the case? If so, should the runtime always be bundled?
(In reply to Marcus Hirt from comment #33) > Do you think that will change with future versions, or will this always be > the case? If so, should the runtime always be bundled? Here are MS developer's comments on the topic: https://github.com/MicrosoftEdge/WebView2Feedback/issues/348#issuecomment-714953769 https://github.com/MicrosoftEdge/WebView2Feedback/issues/341#issuecomment-662719106 The most relevant bit: > We are working with Windows to put WebView2 inbox in a future Windows > version, which means from one point forward, you will no longer need > to carry and deploy the Runtime. Until then, you have to ensure that WebView2 runtime is available somehow: 1. Bundle the runtime installer (web or full version) and run it during the installation of your application. 2. Download and install it during the operation of your application. 3. Ask the users to download and install the runtime. 4. Bundle the binaries themselves (so called "fixed version" deployment), i.e. include them as part of your application. 5. For testing only, install Edge Beta/Dev/Canary. WebView2 documentation explains the options: https://docs.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution PS. Marcus, have you considered re-doing JMC flamegraph with SWT graphics?
I did, but the truth is that most popular visualization libraries are JavaScript these days. I don’t have time porting them all. I just added Graph visualization in JMC, and I’m thinking of trying alternative visualizations of the graphs, e.g. using Cytoscape.
its a pity you really have to check our self if it is already installed or not.. Because i don't have any problem shipping: MicrosoftEdgeWebview2Setup.exe with our product and then invoking it silently under the hood all the time when installing our product and that installer checks if it needs to do anything But it doesn't seem to do that, it always installs it again i think. So you really need to have an installer that checks various things in the registry (why they don't do that in that installer to make it easier...)
(In reply to Johan Compagner from comment #36) > its a pity you really have to check our self if it is already installed or > not.. You don't. > Because i don't have any problem shipping: MicrosoftEdgeWebview2Setup.exe > with our product and then invoking it silently under the hood all the time > when installing our product and that installer checks if it needs to do > anything That's exactly how the runtime installer works and is the recommended way to do it. It installs the shared, auto-updated WebView2 for all applications.
every time i run that online installer it really installs stuff even if i do /silent /install i see it crunching in my task manager for a while It is faster because i think it uses a cached download, but i am 100% sure that it is not just checking some registry and then seeing its already installed and i don't do anything.
Since the plan is to ship WebView2 with Windows in the future[1], shouldn't the plan be to have SWT use it by default, if available, and downgrade to IE if not available? [1] https://docs.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution
(In reply to Marcus Hirt from comment #39) > Since the plan is to ship WebView2 with Windows in the future[1], shouldn't > the plan be to have SWT use it by default, if available, and downgrade to IE > if not available? WebView2 integration isn't fully compatible with the old IE, see the "Limitations and Caveats" section in https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/174084/8/bundles/org.eclipse.swt/Readme.WebView2.md There are some fundamental limitations and some missing APIs. We'll have to change eventually, but now doesn't seem like the right time. You can change the default yourself by setting the the property: -Dorg.eclipse.swt.browser.DefaultType=edge
> You can change the default yourself by setting the the property: > -Dorg.eclipse.swt.browser.DefaultType=edge will this be out of the box working for eclipse 4.19 ?
(In reply to Johan Compagner from comment #41) > > You can change the default yourself by setting the the property: > > -Dorg.eclipse.swt.browser.DefaultType=edge > > will this be out of the box working for eclipse 4.19 ? That's the plan.
Created attachment 285441 [details] Empty_JavaDoc_Hover_Eclipse with Edge browser
Created attachment 285442 [details] Eclipse_WelcomePage with Edge
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt.binaries/+/174085 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.binaries.git/commit/?id=5f32e5152e8912d611ebd7c02e31b3529c480e07
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/174084 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=be82032669b2b022906a83b069d39c7894c5d94c
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt.binaries/+/176262
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt.binaries/+/176262 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.binaries.git/commit/?id=c891009a41010ed8211c6fe85616e8d5fd580e3b
Support for Edge browser integration is release to master and is available from below & onwards Eclipse build: https://download.eclipse.org/eclipse/downloads/drops4/I20210215-0700/
i guess it would be nice then to update: https://www.eclipse.org/eclipse/news/4.19/platform.php to mention this and also say what todo and how to use it? (because you still need to install stuff from MS right?)
(In reply to Johan Compagner from comment #50) > i guess it would be nice then to update: > > > https://www.eclipse.org/eclipse/news/4.19/platform.php > > to mention this and also say what todo and how to use it? > (because you still need to install stuff from MS right?) How to use is documented here: https://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/bundles/org.eclipse.swt/Readme.WebView2.md Please note that Edge integration is currently experimental, it ISN'T a drop-in replacement for the old IE back-end. There are differences in behavior and missing APIs. Platform has multiple issues when running with Edge as a default.
(In reply to Eclipse Genie from comment #46) > Gerrit change > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/174084 was > merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=be82032669b2b022906a83b069d39c7894c5d94c This causes API error on SWT class: The field org.eclipse.swt.SWT.EDGE has been added to a class. I guess we need an API filter update.
(In reply to Andrey Loskutov from comment #52) > (In reply to Eclipse Genie from comment #46) > > Gerrit change > > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/174084 was > > merged to [master]. > > Commit: > > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > > ?id=be82032669b2b022906a83b069d39c7894c5d94c > > This causes API error on SWT class: The field org.eclipse.swt.SWT.EDGE has > been added to a class. I guess we need an API filter update. Oh, that might be. My API checker appears to be broken. OTOH, addition of a constant shouldn't be an error, the version has been bumped.
(In reply to Andrey Loskutov from comment #52) > (In reply to Eclipse Genie from comment #46) > > Gerrit change > > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/174084 was > > merged to [master]. > > Commit: > > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > > ?id=be82032669b2b022906a83b069d39c7894c5d94c > > This causes API error on SWT class: The field org.eclipse.swt.SWT.EDGE has > been added to a class. I guess we need an API filter update. Yes, will add it shortly.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/176305
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/176305 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=0b60d50568d8c34d01ebe565fa4e851a4c07c2b3
Pending items before we close this bug: 1. N&N entry needed for this feature. 2. Raise bug for known issues. 3. SWT FAQ entry: - How to run SWT embedded EDGE browser. - List known limitations
Raised below bug for known issues: 1. Bug 571278: [Edge] Eclipse with Edge browser has multiple issues 2. Bug 571280: [Edge] Workaround failing JUnits with Edge browser 3. Bug 571281: [Edge] Failing JUnits due to Limitation with Edge browser 4. Bug 571283: [Edge] Upgrade WebView2Loader.dll from NuGet package
New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/176449
Gerrit change https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/176449 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=143006812190d874b7928b5d67d40f108674aeb8
Niraj, I'm going to update N&N and FAQ.
(In reply to Nikita Nemkin from comment #61) > Niraj, I'm going to update N&N and FAQ. Ok, please update on below section, which I added today: https://www.eclipse.org/eclipse/news/4.19/platform_isv.php#swt-edge
i would update the url to the readme https://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/bundles/org.eclipse.swt/Readme.WebView2.md to https://git.eclipse.org/r/plugins/gitiles/platform/eclipse.platform.swt/+/refs/heads/master/bundles/org.eclipse.swt/Readme.WebView2.md which shows it a bit nicer formatted for end users, without suddenly having that git ui interface
New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/176500
Gerrit change https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/176503 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=21357db54dc8799dec3a27e664f21f9aadb9dbed
(In reply to Niraj Modi from comment #62) > (In reply to Nikita Nemkin from comment #61) > > Niraj, I'm going to update N&N and FAQ. > > Ok, please update on below section, which I added today: > https://www.eclipse.org/eclipse/news/4.19/platform_isv.php#swt-edge Hi Nikita, Let's complete this by RC1, Thanks!
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/176746 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=7ba9d49c99116d092a1598afd6b522fb072b6afa
New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/swt/+/176875
New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/176876
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/176882
Gerrit change https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/176876 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=3f6c22864608aeb9bc2cf5b9da566d3753ddd7d0
Thanks Nikita for the N&N and FAQ entries, resolving now. (In reply to Eclipse Genie from comment #70) > New Gerrit change created: > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/176882 Since we are done with RC1, raised separate Bug 571528 to track above bug fix for if possible for 4.19 RC2.
Raised below top level bug for tracking further improvements/fixes in Edge: Bug 571909 - [Browser][Edge] Improve support for embedding Edge on Windows
Thanks for implementing Edge support in SWT, but are you sure the documentation is correct: > Note: If WebView2 backend is requested but the runtime isn't found, the Browser will automatically fall back to the Internet Explorer backend. In my tests when no WebView2 pack is installed there is no fallback, instead I am getting an exception and the Browser component is dead.
