[webkit-qt] Injected bundle(s)

Alberto Mardegan mardy at users.sourceforge.net
Thu Jan 24 22:07:39 PST 2013

Thanks Jocelyn and Sergio for your replies!

On 01/24/2013 08:26 PM, Jocelyn Turcotte wrote:
> Since you control the distribution of QtWebKit, would it be possible
> to patch QtWebKit in your packages and add this function as an internal
> API for the use of your first party applications? That would be the
> simplest way I would see to achieve this until we can figure out how to
> handle those sharp use cases.

This might be a possibility, but I'd like to avoid needing a patched 
version of QtWebkit as mush as possible. Patching the packages only to 
export the injected bundle API, as suggested by Sergio, sounds more 
acceptable (but then, I haven't actually checked if a bundle could 
access the cookies storage, so it might be that there are complications).

I've been looking at other possibilities, which require modifying the 
(Qt)WebKit sources but IMHO have greater chances of being accepted upstream:

1) Expose the WebContext::setCookieStorageDirectory() method to Qt apps; 
as far as I can see, this method is currently exposed only by the C 
bindings (see WebKit2/UIProcess/API/C/WKContext.cpp).
Maybe the QQuick WebView could export a string property to allow clients 
to override the cookie storage directory?

2) Use WebKit1, porting the Qt4.8 WebKit QML plugin to QQuick (and 
expose the cookieJar object as a property). AFAIU, WebKit1 is not going 
away very soon, so it might not be a crazy idea to create a QQuick API 
for it too. However, while looking for this possibility, I found that the
file exports some classes which seem to be based on WebKit2 instead. 
This puzzles me a bit. What is this plugin doing exactly?

As a matter of fact (and as hinted in solution #1), we could implement 
the functionality we need even without having full control of the cookie 
jar, as long as we can alter the storage directory according to the user 
account (profile) which is performing the OAuth authentication.

It looks to me that solution #1 should be relatively easy to achieve. I 
think I'll file a bug about it and then go on with the implementation if 
no objections are raised.


More information about the webkit-qt mailing list