Re: [eclipse-ide-wg] A (slightly different) proposal to address the cons

[Christian Dietrich <christian.dietrich@xxxxxxxxx>]

this also affect all the hovers that render htmk, correct?

Am 15.11.2022 um 09:33 schrieb Christoph Läubrich:
> 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
> _______________________________________________
> 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

--
Vorstand/Board: Jens Wagener (Vors./chairman), Dr. Stephan Eberle, Wolfgang 
Neuhaus, Franz-Josef Schuermann
Aufsichtsrat/Supervisory Board: Michael 
Neuhaus (Vors./chairman), Harald Goertz, Eric Swehla
Sitz der 
Gesellschaft/Registered Office: Am Brambusch 15-24, 44536 Lünen (Germany)
Registergericht/Registry Court: Amtsgericht Dortmund | HRB 20621