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