<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 25, 2012 at 1:05 PM, Alex Fiestas <span dir="ltr"><<a href="mailto:afiestas@kde.org" target="_blank">afiestas@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><div>On Wednesday, April 25, 2012 10:23:27 AM Dawit A wrote:<br>
> On Tue, Apr 24, 2012 at 8:13 AM, Alex Fiestas <<a href="mailto:afiestas@kde.org" target="_blank">afiestas@kde.org</a>> wrote:<br>
> > After reading the patch and understanding a little bit more how this work<br>
> > I<br>
> > reached the following conclusion (potentially wrong as before :p).<br>
> ><br>
> > storageDisabled should work as it does right now (without the patch), it<br>
> > does<br>
> > disable any storage and allow reading, which imho it is exactly what you<br>
> > expect from "disable storage".<br>
> ><br>
> > So, how do we enable Private Browsing in AcessManager?<br>
> > By setting a different CookieJar, the default Qt implementation will do<br>
> > the<br>
> > job perfectly storing all the cookies in memory until the jar is destroyed<br>
> > (Private Browsing disabled).<br>
> ><br>
> > Right now any new CookieJar set via QNetworkAccessManager::setCookieJar<br>
> > will<br>
> > be ignored by Integration::AccessManager since at the end kio_http will<br>
> > use<br>
> > the "auto" cookie mode.<br>
> ><br>
> > So, the solution should be:<br>
> ><br>
> > -Fix the support for external QNetworkCookieJar's, this will have to be<br>
> > done<br>
> > anyway since Integration should have support for it.<br>
> ><br>
> > -Fix KWebPage to set a custom CookieJar when private browsing is<br>
> > activated.<br>
> ><br>
> > What do you think? does it make any sense at all this time?<br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<div><br>
> Well actually it is a little bit simpler than that to get to what you want.<br>
> Keeping only the portion of my patch that deals with disabling cookie<br>
> handling in kio_http along with you setting your own custom cookiejar<br>
> through QWebPage::networkAccessManager()->setCookieJar should be sufficient<br>
> for what you are trying to do.<br>
</div></div>I will try to provide a patch, thanks for the support !</blockquote><div><br></div><div>If you wait a litte while I am going to fix this issue once and for all since I want to add proper support for "Private browsing mode" in kwebkitpart. I am sure the reKonq guys/gals will appreciate that as well.</div>


<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>> However, to properly fix the issue of "private browsing mode" for more<br>

> complex scenarios like allowing two separate instances of web browsers to<br>
> share cookies as it is done in other browser implementations (I checked<br>
> Chromium) requires a little bit more involved fix. We would need to use the<br>
> cookiejar and that means we need a way to mark such cookies as private to<br>
> the cookiejar. The trick is to do that without having to modify any of the<br>
> KDE cookiejar code. I will see what I can do about that...<br>
</div>I have been willing to do a small app to load a single KDED for months<br>
now,though I wanted to do it for ease the development of a KDED that very same<br>
app could be used to execute another instance of KCookieJar.<br>
<br>
Flow should be something like:<br>
1-User actiavte's private browsing<br>
2-rekonq executes a custom KCookieJar<br>
   -This could be done automatically within kdewebkit but we are in freeze<br>
   -Once we fix the "Be able to use custom CookieJars with KWebkit" rekonq<br>
could write one to use this custom KCookieJar instance<br>
3-Once private browsing is deactiavted, the small app is closed deleting all<br>
its content.<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Something I really like from that approach is that we keep things "phisically"<br>
separated, kded4 will handle real cookies while the new instance will handle<br>
private-browsing cookies.<br></blockquote><div><br></div><div>Why unnecessarily waste memory ? I personally do not like this idea. For every application that starts its own "private browsing mode" there will be a separate instance of kcookiejar ? That is completely unwarranted. Plus there will most definitely be unforeseen consequences for having multiple instances of kcookiejar running. For example, you cannot predict how the cookie management dialog would behave under such circumstances.</div>


<div><br></div><div>I personally believe there are easier ways to deal with this without having to change any code in kcookiejar. However, I won't be able to know that for sure until I try it and see if it passes all test cases. I will do that soon as I want to have this functionality in for KDE 4.9 at least.</div>


</div></div>