Bugzilla – Full Text Bug Listing
| Summary: | Support a recent Chromium version | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Lakshmi P Shanmugam <lshanmug> |
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | akurtakov, daoenpan, digga1404, eclipse, gautier.desaintmartinlacaze, guillez, jcompagner, jfaltermeier, joerg.specht, jonah, Lars.Vogel, loskutov, ma.becker, maese.chaeller, marcus, mbaudier, mgarcia, niraj.modi |
| Version: | 4.17 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X | ||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=572010 | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 566608, 569095 | ||
|
Description
Lakshmi P Shanmugam
(In reply to Lakshmi Shanmugam from comment #0) > The currently supported v59 is quite old and some sites already report it as > a old browser. > > From https://bugs.eclipse.org/bugs/show_bug.cgi?id=549585#c112 support for > v69 is under works. This bug is to track this work. Hi Guillermo, Do you have a plan, when support for the newer version will be available? i guess if people are starting to move to bootstrap 5: https://getbootstrap.com/docs/5.0/migration/#browser-support-1 then we will have a problem with IE usage in Eclipse but also they drop support for Chrome < 60.. The viable solution right now for Windows seems to be MSEdge contribution in bug 538991 and it should be chromium engine again. Chromium seems to not have gained enough interest and having to redistribute it separately makes it less likely to be uptodate than relying on system installed MSEdge. It would be great to have Chromium in Eclipse because with that the browser widget would use the same browser on all systems instead of different browsers depending on the system, making it easier to create platform-independent applications based on Eclipse. For security reasons alone, it would be essential to have the latest version of Chromium in Eclipse, not an outdated version with known vulnerabilities. I worry that there may be technical reasons or that Equo gives the newest Chromium to paying customers only or that for other reasons this won't happen. In any case, I would like to know the reasons for this and what Equo is planning to do here. @Guillermo @Mauro, could you please tell? Considering the lack of any progress we should start the process or removing chromium builds for M2 at latest. We (Equo) have recently created these contributions related to chromium: [Merged] We helped to fix the broken binaries in linux (https://bugs.eclipse.org/bugs/show_bug.cgi?id=565434) [Merged] Fix the failing build and added docs (https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/175602) [Waiting review] Fix crash on restart (https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/176113) [Waiting review] Mailto links (https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/175587) [Waiting review] Find & Download (https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/175450) The last 3 haven't received too much feedback. We have said that we could contribute the upgrade to cef v69, and the feedback was that it's too old for some. We know that many users and companies are using the current version v59 from eclipse and it solves many problems for them and would be a drawback to remove it from chromium. For other companies that require more up to date versions (due features, security, etc) we offer Equo Chromium Enterprise as a solution. We cannot contribute the very latest version as open source, but we have shown the commitment to contribute v69 and then newer versions, as we move forward in our enterprise updates also. But it is not possible for us to contribute every new version of cef to eclipse, as we offer the very latest commercially and we don't have every single chromium version working. And we think it's absolutely not necessary to always be in the latest version. And if it's necessary for some companies, they have the commercial offerings available. We think it's great to have chromium in eclipse, and we still propose to contribute the update to v69 now and a few months later to a higher version. But we also need some commitment that contributions will be reviewed and welcomed, otherwise it is just too much work to create contributions just in case. So, if the swt team is willing to review and eventually accept v69, we can create it in the next few weeks. Please kindly confirm to move forward with this. Now that we finally have honest talk I'll be direct and give you my side. There is nothing in your offer for me but more work (releng publishing, rust setup in docker images, dealing with failing builds in chromium part, triaging bugs, patch downstreams to skip useless chromium bits and so on) with zero benefit. I never managed to even start it on my Fedora 34 with Gnome thus real review (anything more than proof read code is practically impossible) and chromium versions with so many CVEs is not only not ok to stay but something that has to be removed explicitly. I fully respect your right to decide your way to monetize the work you do and no one has any right to tell anyone what do to unless under some mutually agreed contract but this goes both directions and there is plain nothing offered in return for me and my team work. So here is practical proposal for you to consider - instead of improving chromium in swt, work to improve swt browser support extensibility so you can delivier chromium support entirely as third party component without putting the burden you're putting on committers right now. NOTE: This is my view and doesn't represent Eclipse PMC opinion in any way yet. (In reply to Alexander Kurtakov from comment #7) > I fully respect your right to decide your way to monetize the work you do > and no one has any right to tell anyone what do to unless under some > mutually agreed contract but this goes both directions and there is plain > nothing offered in return for me and my team work. I fully agree, even if that would mean for my company that the money we've already paid to Equo for few Chromium patches was not a good investment after all. > So here is practical proposal for you to consider - instead of improving > chromium in swt, work to improve swt browser support extensibility so you > can delivier chromium support entirely as third party component without > putting the burden you're putting on committers right now. Yep. > NOTE: This is my view and doesn't represent Eclipse PMC opinion in any way > yet. For the PMC vote see bug 572010. (In reply to Mauro Garcia from comment #6) > We think it's great to have chromium in eclipse, and we still propose to > contribute the update to v69 now and a few months later to a higher version. > But we also need some commitment that contributions will be reviewed and > welcomed, otherwise it is just too much work to create contributions just in > case. > So, if the swt team is willing to review and eventually accept v69, we can > create it in the next few weeks. > > Please kindly confirm to move forward with this. Hi Mauro, v69 and newer versions were being discussed ([1],[2]) almost a year ago and we cannot accept v69 now for 4.20 release, it’s too old. There is no point in moving from one very old version to another. We have already spent considerable time and effort in integrating/maintaining Chromium support in Eclipse/SWT and as Alex said this would be more effort with zero benefit. I agree it’s good to have Chromium support in Eclipse but not being stuck with supporting a outdated version. To continue Chromium support in SWT: 1.We require a recent Chromium version not more than 6 months old, if not the latest. 2.Provide developer documentation - Request for code documentation (not build steps) was made multiple times and agreed to (Bug 565507), but we still don’t have it. This blocks the team and the community to make fixes or changes to the code. If we are going forward, to ensure we are not stuck with a old version again, we would expect regular updates to a recent chromium version with eclipse releases. [1] - https://bugs.eclipse.org/bugs/show_bug.cgi?id=549585#c56 [2] - https://bugs.eclipse.org/bugs/show_bug.cgi?id=549585#c112 Repeating here for broader reach: The Eclipse Project PMC has agreed that the time spent on building/infrastructure/reviews/bug triaging for Chromium support in SWT, in its current form, is not providing benefits for the open source community. Setting aside how demotivating it is to work on something that isn't useful, we simply do not have the resources to dedicate to something which can not be used in real applications. The security concerns in the current Chromium support are eroding SWT credibility since part of the project has a hard requirement on a library with many CVEs. Thus the following steps will be taken: * We will stop building and publishing the Chromium support libs for M1 (2021-04-09) unless a patch is contributed by that time, which provides support for a recent, CVE-free Chromium version. * The code and disabled builds will be kept until the end of the current release cycle (2021-06-16) to provide an opportunity for the community to step in if there is interest in keeping support for it. We absolutely want to see the SWT ecosystem grow (but not at the cost of putting at risk regular builds, and the motivation of people working on it). Thus we would support efforts to improve SWT extensibility so that alternative Browser implementations can be provided without the need for changes in SWT codebase or involvement of Platform rel. eng. That is, we want it to be possible to contribute new browser support by an independently driven project. Who would like to help? We do respect your decision, but saying that Chromium SWT is not providing benefits to the open source community or that it's not useful or cannot be used in real applications is just your point of view, but it's not real for many users. Regarding the security concerns, IE and Webkit have less CVE filled since they are not widely used, but I don't think anyone is more secure using IE. If at some point in time we can contribute newer versions, we will get back to see how this could be achieved. Nothing has changed for long enough time. |