wiki:April 2011 Meeting/WebKit2

Version 2 (modified by, 12 years ago) (diff)

Dumped my notes about WebKit2

Current status

  • Sam explained the WebKit2 API using
  • 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 ( 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):
  • 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