We have always used a default web context without providing API to create others. The main reason was that nobody requested it and we haven't needed it either. The main problem of the default web context is that you can't configure anything during construction. This hasn't been a problem so far because all the web context configuration we expose in the API can be configured after construction. But now we need to expose API to allow the user to configure the local storage directory (see https://bugzilla.gnome.org/show_bug.cgi?id=738720), which is a construct only configuration. The default web context was also a problem for our unit tests, because sharing the same context made it difficult to ensure tests cases are independent to each other. So, I think it's time to allow the user to create web contexts or inherit from WebKitWebContext to create a new custom context.
Created attachment 241776 [details] Patch I've reworked all the unit tests to use a different web context making them independent to each other
Should we use a different context for each test? There is value in testing things in a more realistic fashion, that will show issues that happen when one thing happens after another?
(In reply to comment #2) > Should we use a different context for each test? There is value in testing > things in a more realistic fashion, that will show issues that happen when > one thing happens after another? If we need that, we should use the same test. So, if two tests need to use the same context, they could be merged, like we did with the favicon tests, for example. Are you thinking in any concrete test?
Comment on attachment 241776 [details] Patch Makes sense =)
Committed r176256: <http://trac.webkit.org/changeset/176256>