KIO / KWebView and PrivateBrowsing (Cookies)

Alex Fiestas afiestas at
Wed Apr 25 18:05:08 BST 2012

On Wednesday, April 25, 2012 10:23:27 AM Dawit A wrote:
> On Tue, Apr 24, 2012 at 8:13 AM, Alex Fiestas <afiestas at> wrote:
> > After reading the patch and understanding a little bit more how this work
> > I
> > reached the following conclusion (potentially wrong as before :p).
> > 
> > storageDisabled should work as it does right now (without the patch), it
> > does
> > disable any storage and allow reading, which imho it is exactly what you
> > expect from "disable storage".
> > 
> > So, how do we enable Private Browsing in AcessManager?
> > By setting a different CookieJar, the default Qt implementation will do
> > the
> > job perfectly storing all the cookies in memory until the jar is destroyed
> > (Private Browsing disabled).
> > 
> > Right now any new CookieJar set via QNetworkAccessManager::setCookieJar
> > will
> > be ignored by Integration::AccessManager since at the end kio_http will
> > use
> > the "auto" cookie mode.
> > 
> > So, the solution should be:
> > 
> > -Fix the support for external QNetworkCookieJar's, this will have to be
> > done
> > anyway since Integration should have support for it.
> > 
> > -Fix KWebPage to set a custom CookieJar when private browsing is
> > activated.
> > 
> > What do you think? does it make any sense at all this time?
> Well actually it is a little bit simpler than that to get to what you want.
> Keeping only the portion of my patch that deals with disabling cookie
> handling in kio_http along with you setting your own custom cookiejar
> through QWebPage::networkAccessManager()->setCookieJar should be sufficient
> for what you are trying to do.
I will try to provide a patch, thanks for the support !

> However, to properly fix the issue of "private browsing mode" for more
> complex scenarios like allowing two separate instances of web browsers to
> share cookies as it is done in other browser implementations (I checked
> Chromium) requires a little bit more involved fix. We would need to use the
> cookiejar and that means we need a way to mark such cookies as private to
> the cookiejar. The trick is to do that without having to modify any of the
> KDE cookiejar code. I will see what I can do about that...
I have been willing to do a small app to load a single KDED for months 
now,though I wanted to do it for ease the development of a KDED that very same 
app could be used to execute another instance of KCookieJar. 

Flow should be something like:
1-User actiavte's private browsing
2-rekonq executes a custom KCookieJar
   -This could be done automatically within kdewebkit but we are in freeze
   -Once we fix the "Be able to use custom CookieJars with KWebkit" rekonq 
could write one to use this custom KCookieJar instance
3-Once private browsing is deactiavted, the small app is closed deleting all 
its content.

Something I really like from that approach is that we keep things "phisically" 
separated, kded4 will handle real cookies while the new instance will handle 
private-browsing cookies.

At the same time, if wanted we should be able to have multiple private 
browsing sessions.

More information about the kde-core-devel mailing list