Bug 257310

Summary: Rekonq does not stay logged into sites when the option is checked
Product: [Unmaintained] rekonq Reporter: niburu1
Component: generalAssignee: Andrea Diamantini <adjam7>
Status: RESOLVED NOT A BUG    
Severity: normal CC: a.vanloon, fxrh
Priority: NOR    
Version First Reported In: 0.6.1   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description niburu1 2010-11-19 12:09:47 UTC
Version:           0.6.1 (using KDE 4.5.3) 
OS:                Linux

Rekonq does not stay logged into sites when the "stay logged/signed in" option is checked. This happens with facebook, google sites (e.g. gmail, gcal, etc.) and other popular sites. Is this an issue with cookies?

Reproducible: Sometimes

Steps to Reproduce:
1. Open a new tab
2. Go to e.g. gmail and log in, checking the option to stay signed in
3. Close the tab (perhaps the browser?), open a new one again and go to gmail to login.

Actual Results:  
Greeted with the sign-in page.

Expected Results:  
The inbox page with the user signed in appears
Comment 1 Alexander van Loon 2011-01-15 15:58:15 UTC
Could you bug be a duplicate of bug #255591? According to a commenter there the problem might indeed be related to cookies.
Comment 2 Felix Rohrbach 2011-01-15 16:05:31 UTC
Do you have "Configure Rekonq->Network->Cookies->Treat all cookies as session cookies" enabled?
Comment 3 niburu1 2011-01-15 16:18:31 UTC
Apparently this is a duplicate of bug 256319. The solution, as Felix mentioned, is to disable "treat all cookies as session cookies". It would be best to provide a better label/description of the feature or to tell the user somehow what on Earth that feature does. E.g., what is a session cookie? Not many know, I'm sure.
Comment 4 Andrea Diamantini 2011-01-16 11:01:15 UTC
When there are settings you don't understand, please avoid setting them. Not every setting is explained and I know a lot of people does not understand also the "tab" concept (IE6 addicted?).
We have just a form and one line to explain "the setting" not "the concept". Not enough space to explain the HTTP protocol, sorry.
Comment 5 niburu1 2011-01-16 11:08:13 UTC
If that is your advice then I would expect all of the features most people won't understand to be disabled by default! The user will expect that features set by default are *recommended*, and since he doesn't understand what they do, why would he disable them?

I look forward to seeing the "treat all cookies as session cookies" disabled by default in the future.
Comment 6 Andrea Diamantini 2011-01-16 11:27:59 UTC
I didn't say that. The most common and recommended settings are set by default by programmers, usually. But if you wanna change them, also not knowing what this imply... it's your choice, not our bug!
It's like you set "private browsing" saying "it's obvious I'm doing a private browsing! I'm in my private home, with my private pc!" and then you open a bug report saying rekonq history does not work.
Comment 7 niburu1 2011-01-16 11:36:05 UTC
Forgive me if I fail to see the analogy.

Here's the issue. None of the popular browsers, that includes Chrome, Firefox and Opera, have a feature called anything like "treat all cookies as session cookies", nor do they have anything like that enabled by default. Then a user installs and runs Rekonq, checks to see that cookies are enabled and by default accepted, only to find out that when he closes a tab or the browser his cookies are lost.

Also keep in mind that in KDE there are sessions as well and that the user might confuse those with browser sessions. It's not crazy to think that the rekonq feature is meant to apply to KDE sessions rather than browser sessions.

Anyway, the feature's handy and possibly even well-labeled, but it shouldn't be set by default if you ask me.
Comment 8 Alexander van Loon 2011-01-16 11:55:02 UTC
I agree with niburu1. My comment on bug #255591, which is also a duplicate of bug #256319:

‘I’m having this problem as well, a related problem to be exact. Firefox would always restore the Facebook start page for me and rekonq does not because it forgets the login. If I’m correct this is intended behavior in rekonq according to the comments in bug #256319. If the cookie policy is what is causing this bug, then maybe we should file a new bug, because rekonq’s default policy isn’t good considering that other browsers do remember logins.’

I think the current cookie policy is not a good idea, if the browser forgets cookies by default it takes a lot of work to log in again on many sites, while Firefox, Chrome and other browsers do not forget the cookies and log me in automatically as their default behavior. I believe it’s best to keep the option for the security conscious users of rekonq, but the default settings had better mimic the common other web browsers.
Comment 9 Felix Rohrbach 2011-01-16 18:12:26 UTC
The cookies settings are shared with konqueror, so you have to ask them to change the naming.
Comment 10 niburu1 2011-01-16 18:28:20 UTC
Ok, well that changes things. If KDE decides to keep that setting enabled by default I hope most popular distributions don't.  I should file some wishes...
Comment 11 Andrea Diamantini 2011-01-17 09:56:07 UTC
Cookie settings are not exactly shared with konqueror, but are kde-wise. And just to be precise, treat all cookies as session cookies is not FOR SURE default kde policy. Someone set it and I sincerely doubt it was your distro.
Comment 12 Alexander van Loon 2011-01-17 16:47:29 UTC
niburu1, could you please post the bug numbers of the wishes you filed in a comment here? I’d like to keep track of them too.

Andrea, I’m a bit confused. If it was not the KDE developers who enabled this setting and not the packagers of the distribution either (I’m using Kubuntu’s packages here, not sure what niburu1 is using?) then who could have been? I thought only those two parties ever change default settings and no one else, so who else could have changed them?
Comment 13 Andrea Diamantini 2011-01-17 16:56:59 UTC
uhm... IMHO there are 2 possible suspected:
1) user
2) a bug/crash during one rekonq private session (that never happened here) that obviously enables that settings on-the-fly to maintain privacy.
Comment 14 Felix Rohrbach 2011-03-21 21:57:18 UTC
Guess we can close this, as there is no bug...