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!
