[webkit-qt] QtQuick WebView and QNetworkAccessManager

[Jocelyn Turcotte]

On Thu, Dec 06, 2012 at 05:19:34PM +0100, Alberto Mardegan wrote:
> On 12/06/2012 03:07 PM, Jocelyn Turcotte wrote:
> >Ok, I'm not aware of this kind of use case being on the roadmap.
> >The only way I could see this being possible in the near future would be that you allow only one WebView to load at a time, and that we add some WKCookieManager* alike API to reset the cookies each time you want to show a different account.
> 
> That could be done, yes.
> 
> >The backend of WebKit2 is still moving a lot. For example with Apple currently doing work to have all the networking done in a separate NetworkProcess, to allow multiple WebProcesses. It's difficult to see a way to expose the QNetworkAccessManager in the public API the same way that it is with WebKit1.
> 
> The only way I can see to achieve what I need (actually our current
> implementation can do even more, like executing javascript code to
> prefill form fields and press the submit button) is to make
> WebProcess a simple tiny binary and move all its functionality into
> a library (maybe having an API as close as possible to WebKit1);
> then one could make one's own WebProcess implementation, if the
> WebView had an API which allowed selecting the WebProcess binary to
> execute.
> 
> Do you think that the above might make sense, or am I missing some
> important details?
> 

There is something that does something similar which is called an InjectedBundle. A .so file whichs path is given to the WebProcess that will be loaded and accessed through a set of internal APIs. It is passed through WebContext::create, which we currently fill with an empty string in QtWebContext::defaultContext. The main purpose of this mechanism is testing.

We can't guarantee binary compatibility for bundles, so there is no plan to expose setting a custom bundle path through the public API. However if you would like to maintain a minimal set of patches on top of QtWebKit to add advanced WebProcess functionalities, I think that this would be one of the less painful way regarding maintainance. The internal API of bundles will change, but should be somewhat stable between releases.

The best way forward is still to agree on common functionalities that we could add to the public API, so please use at your own risks.

For JavaScript execution on the page, there are already some functionalities in QQuickWebViewExperimental, but some of those might change until we move them to QQuickWebView. Any feedback on experimental APIs would be welcome meanwhile.

// Jocelyn