[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [eclipse-ide-wg] A (slightly different) proposal to address the constant struggle with browser support in Eclipse
|
As far as I know there are already some efforts in bringing chromium
support back to SWT, so we can maybe just leave that out.
Beside that, I think the "Browser" Widget itself is misleading, it is
far from being something most people understand when the hear "Browser".
So one approach would be to leave the Browser widget alone and simply
have a new "WebView" widget that works like you described in a portable
way with just local rendering. But probably this is more a discussion
for SWT project than for the IDE-WG?
Am 15.11.22 um 09:24 schrieb Martin Lippert:
Hey!
I would like to propose and discuss a slightly different approach to address the browser integration issues and difficulties that we suffered from over the years.
My quick summary of the situation:
- support for the system browser in SWT is a constant source of issues and difficulties
- the support is outdated and problematic - and I don’t see a solution for this coming up anytime soon
My proposal:
- remove the system browser integration from SWT altogether
- ship a Chromium-based rendering engine as part of SWT
The details:
- there are different technical proposals around to integrate Chromium with SWT (e.g. (J)CEF and Electron offscreen rendering)
- pick the most promising one (performance-wise probably CEF)
- include the latest (CEF) runtimes that are available
The security/CVE question:
- restrict the rendering engine to work on local resources only (trusted resources)
- restrict the rendering engine to basically "not render anything from the internet“ (not trusted resources)
- this would allow us to have a solid rendering engine inside of SWT to implement HTML/CSS-based UIs in SWT, show hover content, javadoc help, do a real cool terminal integration, etc.
- this would avoid the need to always ship the latest Chromium runtimes on the same day. Instead, we could just include the latest Chromium runtimes that are around when building an SWT release - and don’t worry about updating the rendering engine independently all the time a new CVE fix comes along
This would follow (at least to a certain degree) the way VSCode uses Chromium and Electron for their UIs. Their chromium version is way behind the latest one that is available, but they don’t always need the latest CVE fixes since there they use the embedded Chromium to render their own content - not random stuff from the internet.
What do you think?
Cheers
Martin
_______________________________________________
eclipse-ide-wg mailing list
eclipse-ide-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/eclipse-ide-wg