== Current status == * Sam explained the WebKit2 API using http://trac.webkit.org/wiki/WebKit2 * Huge improvement over last year * It switched from a science project to a real browser * They had some issues with designing a Browser API (lots of classes need to be exposed but it is difficult to know which one specially are required to be) * They chose a C API (to avoid the fragile class problem in C++) but it may not have been a great choice: the Qt people do not use the WebKit2 API for example. * However the Gtk community sided with it. * Apple will push their out-of-process plugin code to the plugin/ directory. * However they want to *replace* one of our 5-6 implementations instead of adding yet another one. * DRT rewritten but did not have the same functionnality as the old one. * Problems with EventSender as it needs to run events synchronously. == Merging WebKitTestRunner and DRT == * Sam was not sure how much could be merged? * Using code generator (IDLParser.pm) instead of manually writing the JS properties / methods could be a way to avoid duplicating code * Current problem: people write a new test that uses a new or existing feature in DRT and WebKitTestRunner does not pass.... * Solution: IDL based generation (however some implementation '''will need''' to be different) * There will still be some amount of overlap between the 2 * Alexey is proposing a new library to have consistent results as it was determined that ports differ in the way they dump their results ** "We need to merge DRT with itself" == API InjectedBundle == * Kind of plugins to the Browser (they can be used to implement extensions) * Bits of code that you can inject to the web-process associated with a Browser. They can also listen to events. * All data in InjectedBundles should be considered untrusted. * It is basically an object graphs * It can be thought of as an "agreed-upon API for objects" * One of the nice feature of this API is that it does not need to expose the protocol * However it induces a lot of boiler plate code (mostly type checking) * Very similar to WK objects * Maybe add a better abstraction for dictionnary or array. == WebKit 1 - 2: Code sharing == * Talk about sharing the key bindings in Gtk? ** Solution: Push to WebCore/platform so that they can be shared * Example: WindowsMessageBroadcaster * To enable code sharing, we need to have more logic in WebCore! == Missing from the current implementation == * Multiple processes in the same tab (a la Chromium) * Chromium actually has a limited number of processes and change WebKit instances on the fly * Chromium process models (for reference): [https://sites.google.com/a/chromium.org/dev/developers/design-documents/process-models] * Rendering PDF * Stability is still not quite there yet * Refining how the sandboxing works (uses fancy mac implementation of sandboxing) * Want to move networking / filesystem access out of the web-process * Threaded mode is dead at the moment (should work if you have no processes at all), *may* want to be brought back but it is a challenge * Similar flag in Chromium, very handy for certain platform * low-level communication code is very specific to the platform! * Accessibility is supported on Mac but kind of difficult... Does not work on Windows and it will be difficult to implement * Chromium may be sharing the tree across process boundaries but WebKit2 is not == Multiple processes for the same browser == * Envisioned * Would like to but lots of changes required