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
WebKit/qt/declarative/plugin.cpp
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.
Ciao,
Alberto
_______________________________________________
webkit-qt mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-qt
