HEADS-UP: [9] New WebKit + compiler upgrade for FX 9

[Anton V. Tarasov]

Hi Mike,

 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"...

Thanks,
Anton.


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?
>>
>>
>> Thanks!