HEADS-UP:  New WebKit + compiler upgrade for FX 9
Anton V. Tarasov
anton.tarasov at oracle.com
Tue Feb 24 12:03:21 UTC 2015
From the very beggining of the WebView project the idea behind it was to provide deep integration
with JFX and the Java platform itself. That, btw, was one of the reason why the choice was made in
favor of WebKit, which provided a good level of flexibility. As result, the WebView component has
become a true JFX Node, smoothly fitting in the GUI (for instance, even the HTML input controls are
made up of their JFX counterparts). So, WebView rendering design was subordinate to JFX architecture
and its threading model.
Also, the things like images and media processing are also integrated into JFX. What's specially
important - networking. All the connections and data exchange are performed on behalf of the Java
platform, allowing for the corresponding Java security policy to be applied. Thus, WebView relies on
JFX and Java in terms of global security (this of course doesn't cover the lowlevel security of the
native code where we rely on WebKit itself).
I'm not aware of the details behind the Chromium "sandbox", but AFAICS its total sandboxing is
achieved by means of deep integration with platform API (on every supported platform). This seems to
be quite distant from the concepts behind JFX/WebView. What comes into the mind immediately is the
fact that Chromium model demands a separate renderer (in a separate process) per sandbox, whereas
JFX has a single Render thread on which WebView is rendered as well. So, switching to this
architecture would either require serious rewrite of JFX (making it subordinate to WebView), or
complete separation of WebView itself, virtually making the embedding model "heavyweight".
Heavyweight embedding has its own pros and cons. However, the fact is that the embedding model
initially chosen for the web component was "lightweight".
So, I can just repeat what Kevin said: "I wonder if that might make sense some day"...
On 21.02.2015 1:35, Kevin Rushforth wrote:
> Quick answers:
> 1) Yes, we hope to get on a more regular cadence with updates. This one was particularly painful
> because WebKit moved to requiring C++11 meaning it was dependent on the compiler upgrade. The next
> one might be somewhat painful as well since they have moved from Qmake to Automake.
> 2) We've only thought about using Blink in a "Hmm, I wonder if that might make sense some day"
> sense. We haven't given any serious thought to it. Anton might have some thoughts on the
> sandboxing question.
> -- Kevin
> Mike Hearn wrote:
>> The changeset patch is 185 Mbytes and touches 11,688 files including added, removed,
>> modifiled files. I tried generating a webrev, but it is just too big and unweildy to upload
>> (over 1.6 GBytes).
>> A 185 megabyte patch!? That is ...... mind boggling. I don't envy you guys!
>> Couple of questions:
>> 1) I'm curious if there are plans to sync with WebKit upstream more frequently from now on to try
>> and reduce the pain of upgrades. As WebKit is so complex and security sensitive, and not
>> sandboxed in the same way as Chrome, regular updates seem vital for security. Of course this
>> doesn't matter if you are just rendering your own content but for displaying potentially hostile
>> content, it seems important.
>> 2) Have you considered using Blink instead, perhaps that way you would get the sandboxing tech
>> from Chromium? Or does the WebKit JFX uses now have cross-platform sandboxing in it as well?
More information about the openjfx-dev