Frequent loss of session data (since around 2016-11-28)
Open, HighPublic

Description

Lately I often get error "Sorry! We could not process your edit due to a loss of session data. Please try saving your changes again. If it still does not work, try logging out and logging back in. " while saving edits on EN-WIKI. In the past on a rare occasion when I got this error I could just press save again and it would work. This time multiple saves do not help nor relogging. I suddenly can not edit at all on any pages. I did some experiments trying to understand the issue, and it seems like I can use tools that edit the page in my name. The only workaround I found was to switch browsers. I usually edit in Firefox and I switch to Chrome.


This is Firefox bug #1319403 (cookie limits seem to be applied to the second-level domain). Workaround: set network.cookie.maxPerHost as an integer much higher in Firefox's about:config menu.

Specifically:

  1. Open a new tab or window
  2. type or paste about:config and click [Enter]. (There might be a warning screen after this)
  3. right click anywhere in the table of results
  4. select New
  5. select Integer
  6. type or paste network.cookie.maxPerHost as the preference name, and click [ok]
  7. type a value (see below), and click [ok]
  8. Done!
    • (You might need to reload the page, or re-log-in, or restart your browser, for the fix to start working. But probably not.)

Value: any number between 200 and 2000 should work fine. Estimate 5+ cookies per wiki, and only count the project (e.g. Wiktionary) that you access the most languages of.

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes
Tgr added a comment.Jan 6 2017, 1:44 AM

Maybe "Due to a browser bug users on Firefox 50 might occasionally get logged out or fail to save their edits. Workaround: enter about:config in the address bar and set network.cookie.maxPerHost to 5000."

That workaround does not work for me - my about:config (FF 50.1.0) does not seem to have anything named "network.cookie.maxPerHost" (though searching for "network.cookie" brings about a number of similarly named variables).

Maybe "Due to a browser bug users on Firefox 50 might occasionally get logged out or fail to save their edits. Workaround: enter about:config in the address bar and set network.cookie.maxPerHost to 5000."

I'd do away with the "occasionally" (for me, it's more like almost always) and say "some users" instead.

Tgr added a comment.Jan 6 2017, 2:25 AM

That workaround does not work for me - my about:config (FF 50.1.0) does not seem to have anything named "network.cookie.maxPerHost" (though searching for "network.cookie" brings about a number of similarly named variables).

You probably need to create a new integer key by that name then.

Alexia removed a subscriber: Alexia.Jan 6 2017, 6:21 AM
Krinkle removed a subscriber: Krinkle.Jan 7 2017, 6:54 AM

How comes I suddenly find myself with hundreds of cookies for the wikipedia.org domain (and the others)? I thought we were still trying to reduce them (T110353), but it looks like many months of work have suddenly been reversed.

Whatever the limit might be for cookies, it's quite easy to reach it with hundreds subdomains and a dozen cookies for each...

I've just deleted all my cookies euwikiGeoFeaturesUser2, WMF-Last-Access, CP, UseCDNCache, UseDC, cpPosTime, which were the biggest offenders. I'm leaving in place the less common VEE, GeoIP, wikiEditor-0-toolbar-section etc. Some of these are not quite necessary and could be eliminated; I suggest to file a separate bug for each recently introduced cookie. If this bug continues, I'll be forced to re-enable Cookie Time to reduce the number of cookies.

Anomie added a subscriber: aaron.Jan 7 2017, 10:26 PM

Let's see what we can find out from some quick searches.

euwikiGeoFeaturesUser2

Added for T103017: Use EventLogging to track geo feature usage.

WMF-Last-Access

https://wikitech.wikimedia.org/wiki/Analytics/Unique_Devices/Last_access_solution describes this one.

CP

Originally added in rOPUP4c6a29bb3c57: wikimedia.vcl: set CP ('Connection Properties') cookie in vcl_deliver. Not sure whether it's functional or only for analytics of some sort.

UseCDNCache

Added for T121440: Dedicated post-edit cache busting cookie to prevent stale reads (session consistency). Looks like some part of trying to make multiple datacenters work, ask @aaron.

UseDC

Added for T91816: Add code to enable setting sticky DC cookies for POST requests. Looks like some part of trying to make multiple datacenters work, ask @aaron.

cpPosTime

Added in rMWc954a4efe8cd: Use cpPosTime cookie for same-domain redirects on DB change. Another one to ask @aaron about.

VEE

I believe this is whether you last used VisualEditor or the normal wikitext editor.

GeoIP

This one at least is documented on https://wikimediafoundation.org/wiki/Cookie_statement. Stores GeoIP data for geo-targetted notices.

wikiEditor-0-toolbar-section

That one's from the WikiEditor extension, remembering which "section" of the toolbar is selected.

Tgr added a comment.Jan 8 2017, 8:29 AM

Let's move the cookie discussion to T110353.

Florian added a subscriber: Florian.Jan 9 2017, 7:57 PM

In Firefox 50.1.0 I don't see a key named network.cookie.maxPerHost - is the workaround suggesting to create this key, is so what datatype?

Tgr added a comment.Jan 10 2017, 12:57 AM

In Firefox 50.1.0 I don't see a key named network.cookie.maxPerHost - is the workaround suggesting to create this key, is so what datatype?

Yes. The datatype is int (0-65535).

Billinghurst added a subscriber: Billinghurst.EditedJan 16 2017, 12:38 PM

Weirdly I hit this problem on one of two PCs just this week, the FF config of extensions is about the same. Only real difference is the one with the issue is older, does most of my crosswiki work, and has many (old) cookies, and has now been accumulating all the VE cookies (die damn spot!) so that probably tipped it over the edge this weekend.

Noting that I only had the issue on the WPs, editing elsewhere across WMF was fine, It was also only due to editing, when I was performing admin actions (views/logs/deletions/blocks) there was no issue, only editing.

If I could have one cookie to say "no VE" for me for all wikis, rather than one per wiki, that would suit me really fine.

I've got the same problem today on sh.wiki and when the second (or third) edit failed again I recorded the cookies from the developer console. I doubt they are very enlightening, but here they are:

Savh added a subscriber: Savh.Jan 19 2017, 11:05 AM

Started happening to me again :/

Is there anything I can do to help debugging this, or is everything known?

Assuming you're using Firefox, you could try the network.cookie.maxPerHost workaround described at the top of this task and confirm that it works for you, or poke upstream at https://bugzilla.mozilla.org/show_bug.cgi?id=1319403 to get on fixing this already.

Koavf added a subscriber: Koavf.Jan 24 2017, 6:30 AM

This about:config workaround is not happening for me. Is this still a problem for others? It's driving me up the wall.

Tgr added a comment.Jan 24 2017, 7:49 AM

I can verfiy that the workaround is working on FF 50.1.0 / Ubuntu. (Steps to reproduce: log in on enwiki, then start opening links to other wikis' main pages from the language panel on the left. After opening about the third of them, you won't be logged in anymore.)

Works for me. I did set a BIG number, 5000 from memory, as I do have lots of cookies from 800 wikis. @Koavf, did you set type as INTEGER??? If not, it will fail.

Koavf added a comment.EditedJan 24 2017, 4:31 PM

@Billinghurst I can only make it a String value. It won't let me create it as an Integer (or Boolean, which of course I don't want). Edit: Deleted the entry and tried again. I'll complain here if it doesn't work. Thanks, guys.

Billinghurst added a comment.EditedJan 25 2017, 5:03 AM

@Koavf

Copy the name to your clipboard

Delete the parameter. Close and reopen your browser and (re)create it. When creating, right click > New > (choose) integer and then add your detail again. [PS. Don't feel bad, my first go wasn't correct, and why I amended the details up top.

Your problem is that string cannot count to your value so you have the default.

Happening to me in bnwp again.

@Bodhisattwa: Please see previous comments. If you have a specific question, please ask your specific question, as "me too" comments do not help anyone, sorry. :)

Pinging Analytics as this probably means that the various cookie-based stats we have are unreliable for Firefox.

If we have to live with this in the long term (looks like upstream haven't quite made up their minds yet), we can probably push most cookies to the second-level domain. For analytics-oriented cookies there is no reason not to, and for user preferences, consistent cross-wiki behavior would almost be a good thing - except that it will only be consistent within different language editions of the same project. That's pretty confusing but not impossible to live with. (OTOH most user preferences should work fine in localStorage, we would only have to fix T121646: Provide featureful Local Storage abstraction in MediaWiki core so that we can handle expiry.)

Nuria moved this task from Incoming to Q2 (October 2017) on the Analytics board.Jan 30 2017, 5:35 PM
Matiia added a subscriber: Matiia.Jan 31 2017, 6:17 PM
Aklapper edited the task description. (Show Details)Jan 31 2017, 9:00 PM
Aklapper edited the task description. (Show Details)

Thanks for the ping, but the only cookie-based stats take session loss into account. We'll keep in mind for future work, untagging for now.

Quiddity edited the task description. (Show Details)Feb 21 2017, 8:09 PM
Quiddity added a subscriber: Quiddity.

The problem appeared today again (message). Only after removing all the cookies I could save a page again.

The problem consists also out of:

  • almost endless amount of cookies for Wikimedia sites, while I login only in one place!
  • storage of too many settings in the cookies, including the annoying message which editor I want to use while I am already editing!
  • all clicked away banners appear again!

There is just one conclusion: this cookie system is broken.

There is a maximum of 30 days that I could stay logged in, but I do not even reach those 30 days if I have this error every week.

Please fix this broken system!

  • Keep preferences in the preferences and not elsewhere
  • If a message is shown and the user can choose something (like which editor to use), save this in the preferences and never ever in cookies!

Thank you!

The Firefox bug https://bugzilla.mozilla.org/show_bug.cgi?id=1319403 has apparently been fixed and it currently planned to be released in Firefox 54.

Thank Goodness.

There is a maximum of 30 days that I could stay logged in, but I do not even reach those 30 days if I have this error every week.

One small note, the old "30 days" limit was increased to 365 days, a few months ago. (T68699) :-)

For us highly-active cross-wiki Firefox users, the best solution is: (A) to do the fix described in the task description, and (B) wait for Firefox54 to fix it properly (it's launching as the official version in June, according to https://en.wikipedia.org/wiki/Firefox_version_history#Firefox_54 ). (The other ideas sound good to me, but aren't likely to change before June!)

In the meantime, maybe we should include a note (link to a page that explains it in simple terms?) this in the error message? It's bound to be a very common cause for this problem, and it could be helpful for users to know how to solve it.

Tgr added a comment.Feb 28 2017, 12:00 AM

The Firefox bug https://bugzilla.mozilla.org/show_bug.cgi?id=1319403 has apparently been fixed and it currently planned to be released in Firefox 54.

Where by "fixed" they mean that they will now delete cookies randomly instead of starting with session cookies :-/

In the meantime, maybe we should include a note (link to a page that explains it in simple terms?) this in the error message? It's bound to be a very common cause for this problem, and it could be helpful for users to know how to solve it.

Good idea. I've put a simple version at https://www.mediawiki.org/wiki/Firefox_users_and_session_loss_bug
If a dev agrees, then please update the string Mediawiki:Session fail preview (wherever that is stored) to include a link to that mediawikiwiki page, using the text "Firefox users, please see this page." (linking the whole sentence). Or similar.

Reedy removed a subscriber: Reedy.Feb 28 2017, 2:07 AM

The Firefox bug https://bugzilla.mozilla.org/show_bug.cgi?id=1319403 has apparently been fixed and it currently planned to be released in Firefox 54.

Where by "fixed" they mean that they will now delete cookies randomly instead of starting with session cookies :-/

There doesn't seem to be much random about it, it looks like they're going with basically a straight LRU now with the only potential randomness being in choosing the specific cookie if there's a tie for LRU.

Hi all, @Kusurija fixed the problem temporary by increasing network.cookie.maxPerHost to 4000 (if 5 cookies per project it should be enough even all 750+ projects were counted together and he was editing all of them) but it appeared again. I adviced him to increase the value to 10000 (to be sure it isn't the same problem) but it didn't help. Symptoms are the same as this problem so I'm not creating new ticket. Can somebody tell me how can he fix it?

P.a.a added a comment.Tue, Mar 28, 8:12 AM

@Urbanecm the (default) maximum number of cookies is 3000, so you have to increase that too through the network.cookie.maxNumberpreference.

BTW would it be fixed on our side anytime? Or is this just monitoring task?

Billinghurst added a comment.EditedTue, Mar 28, 9:05 AM

Hi all, @Kusurija fixed the problem temporary by increasing network.cookie.maxPerHost to 4000 (if 5 cookies per project it should be enough even all 750+ projects were counted together and he was editing all of them) but it appeared again. I adviced him to increase the value to 10000 (to be sure it isn't the same problem) but it didn't help. Symptoms are the same as this problem so I'm not creating new ticket. Can somebody tell me how can he fix it?

I have 5000 working fine, and there wouldn't be that many users who do more xwiki work than myself. (10s to 100s of people max). Do ensure that they have type set as integer, otherwise it won't be counting.

BTW would it be fixed on our side anytime? Or is this just monitoring task?

@Quiddity, this is a good question. Are we managing what has become a little of cookie bloat? Or at least are the prime designers at least thinking about this issue? Can some of the wiki specific cookies be domain specific? Even if one became x-domain that would reduce the numbers.

Nirmos added a subscriber: Nirmos.Tue, Mar 28, 10:17 AM

BTW would it be fixed on our side anytime? Or is this just monitoring task?

@Quiddity, this is a good question. Are we managing what has become a little of cookie bloat? Or at least are the prime designers at least thinking about this issue? Can some of the wiki specific cookies be domain specific? Even if one became x-domain that would reduce the numbers.

See T110353. Krinkle has significantly reduced the number of cookies by moving saved values from cookies to localStorage and sessionStorage, as well as fixing blatant mistakes like https://meta.wikimedia.org/w/index.php?diff=16372260.

When I checked the number of cookies I had on March 9 on svwiki, it was 14. Today it's 10. And that number will only continue to drop because there are changes that have been merged that switches from using cookies to (local|session)Storage. In about a month, I expect to see no more than 6 cookies (CP, VEE, WMF-Last-Access, xxwikiSession, xxwikiUserID and xxwikiUserName), assuming that no temporary things like fundraising banners or steward vote eligible stuff pops up.

I have 5000 working fine, and there wouldn't be that many users who do more xwiki work than myself. (10s to 100s of people max). Do ensure that they have type set as integer, otherwise it won't be counting.

I adviced adding the variable to config previously and it helped, so probably it is an integer but I'll ask him.

Hi all, @Kusurija fixed the problem temporary by increasing network.cookie.maxPerHost to 4000 (if 5 cookies per project it should be enough even all 750+ projects were counted together and he was editing all of them) but it appeared again. I adviced him to increase the value to 10000 (to be sure it isn't the same problem) but it didn't help. Symptoms are the same as this problem so I'm not creating new ticket. Can somebody tell me how can he fix it?

I have 5000 working fine, and there wouldn't be that many users who do more xwiki work than myself. (10s to 100s of people max). Do ensure that they have type set as integer, otherwise it won't be counting.

It really is an integer. There was 4000 previously and it was working but it suddently stopped working with no reason and started giving the same kind of error. Any solution came to my mind didn't help. This problem is in some way different. It affect only Wikipedia not other families.

@Urbanecm the (default) maximum number of cookies is 3000, so you have to increase that too through the network.cookie.maxNumberpreference.

network.cookie.maxNumber was increased too but it do not work.

I'm receiving some emails from @Kusurija, this problem stops him with his work and can't do anything but wait for fixing the problem.

BTW why we don't have just one cookie with random (or permanent) user id which is sent after all requests at all WMF's projects, everything else can and should be stored serverside and anonymous shouldn't be allowed to set anything permanently (only valid to the end of current session) and politely asked to create an account.

Billinghurst added a comment.EditedSat, Apr 1, 6:23 AM

brute force check: suggest going in an deleting a swathe of wikipedia cookies and see whether that removes the problem. Or consider one of the add-ons that allows counts and the like to get you a better idea of what is the issue.

I'll ask him.

Just thinking loudly: Interesting is that it usually doesn't work but sometimes the system allows him to save an edit, https://cs.wikipedia.org/w/index.php?title=Diskuse_s_wikipedistou:Kusurija&diff=14865891&oldid=14865643 for example.

brute force check: suggest going in an deleting a swathe of wikipedia cookies and see whether that removes the problem. Or consider one of the add-ons that allows counts and the like to get you a better idea of what is the issue.

He was deleting cookie after cookie and it did not fixed the problem. However, sometimes the server allows to save an edit without any deleting. The server of course was sending deleted cookies again and again. Here is the list of cookies he tried to delete.

I don't know if you but I really have no idea where is the problem and if it is really the same problem (even I think so).

Affected cookies

All of following cookies were deleted multiple times but it didn't fixed the problem.

  • WMF-Last-Acces
  • cpPosTime
  • cswikiUserID
  • cswikiUserName
  • cswikiSession
  • CP
  • UseDC
  • UseCDNCache
Urbanecm moved this task from Backlog to Watching on the User-Urbanecm board.Sun, Apr 2, 11:27 AM