Behavior of cookies without expiration (supposed to be "session" duration) is unpredictable and inconsistent
Reported by
teo8...@gmail.com,
Jun 26 2016
|
||||
Issue descriptionExample URL: Steps to reproduce the problem: 1. visit a web page that sets a cookie without an expiration date (nor max-age) 2. close all Chrome tabs. 3. Close Chrome, meaning hit the square button on the bottom-right of the screen and swipe Chrome away 3. open Chrome again and visit the same page again What is the expected behavior? Since the cookie has no expiration date, it is supposed to live "until the current session is over". Since all Chrome tabs have been closed and Chrome itself has been closed, the previous session should be considered over, hence the cookie should have expired What went wrong? At random times, unpredictably, the cookie is still sent to the server, as if the session hadn't finished. Sometimes the behavior is as expected. The concept of "when a session is over" appears to be fuzzy on Android. It has to be well-defined and 100% predictable. Did this work before? N/A Chrome version: 51.0.2704.103 Channel: n/a OS Version: 5.1 Flash Version: Shockwave Flash 22.0 r0
,
Jun 26 2016
Also, I believe that swiping apps away on the most recent list just removes it from the history list, rather than killing the apps (Which may not be running in the first place), which is an Android, not Chrome, behavior.
,
Jun 27 2016
> I suspect this is because Android will sometimes run Chrome in the background, and sometimes not. Yes, it seems almost obvious. And that's the issue. It's just unacceptable that the user can't reliably *know* whether he is in the same session or not, and have a way to *decide* to close a session. It's simply something that you must be able to control. > Seems like a lot of thought should go into whatever action we take here, Well it's about time to start thinking then. It's been 7 years. > if any Something definitely must be done. > And if we have a tab open that relies on session state, should we > really break it? Good question. It's kind of ironic though that you worry about that while we have https://bugs.chromium.org/p/chromium/issues/detail?id=476390 which basically means that, if you have a tab open that relies on ANY kind of state, it is guaranteed to break, and Chrome has never given a sh** about it.
,
Jun 27 2016
Just to clarify: > it is guaranteed to break I mean it is *already* guaranteed to break sooner or later, without changing any current behavior (and you don't even need to close a tab, it can happen by just triggering an intent, such as by uploading a file)
,
Jun 27 2016
That sounds like an issue with Android's lifecycle management - Chrome can't prevent Android from killing it, so seems more of an Android bug, though the problem is exacerbated by Chrome's large memory footprint (Which is something that the Chrome team *is* currently looking at). Regardless, seems like this issue goes far beyond the network stack. Just clearing session cookies from the cookie store when Chrome resumes, without a promise to also kill and then reload any displayed webpages, makes very little sense. So I'm going to go ahead and remove the network label.
,
Jun 27 2016
> That sounds like an issue with Android's lifecycle management - > Chrome can't prevent Android from killing it https://code.google.com/p/android/issues/detail?id=53088#c19
,
Jun 29 2016
,
Jun 29 2017
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 29 2017
The usual bullshit: the issue gets archived "because" it hasn't been fixed. |
||||
►
Sign in to add a comment |
||||
Comment 1 by mmenke@chromium.org
, Jun 26 2016